本文討論軟體設計中的決策，特別是關於將較大的系統拆分為多個可獨立部署的服務端點。不會特別討論【服務端點設計】，但我想探討一下為建立多個服務應用程式進行構思的階段。
面對複雜問題，通常試圖理解複雜性的各部分。將問題拆解為更易於理解和處理的小模組，可以更有效地應對。
如同在許多產品/專案管理週期中描述的，對現實生活問題，通常直覺驅動。我們並沒有使用某種公式理解前往需要簽證的國家所需步驟。我們逐步瞭解到需要簽證才能旅行，慢慢掌握需要哪些檔案、哪些表格需要填寫及咋填表。當我們處理其中的一步，不會在腦海中保留整個過程的所有細節，而是專注當前任務。這與任務完成規模有關。真正標準是時間或進度安排、執行任務的精力、認知能力及它與任務熟悉度的關係，甚至包括執行這些任務的物理地點（如領事館與照相館等）。
軟體開發亦是如此。雖然多年“瀑布式”開發流已廣泛應用，但最終主要還是基於啟發式和經驗的估算技術（如規劃撲克、T恤尺寸估算）及敏捷過程佔據主導。正如在現實，我們嘗試不過分細化規劃整個過程，而是根據最新的進展來把握整體方向。
同樣理念也適用於根據問題建模的軟體。開始將它們拆分為不同應用程式，目的是更容易管理單個應用程式，更快開發和部署，並減少依賴關係，最後還帶來更多技術選擇的自由。沒有一套完整流程適用於所有情況。我們會檢視各部分，並認識到我們在設計模式或技術方面的集體經驗，努力選擇最佳方案並應用。
一種用於理解和解決軟體設計複雜性的技術是領域驅動設計（DDD）。DDD提倡基於業務現實建模，並與我們的用例相關。隨其熱度下降，很多人可能忘記DDD方法實際上在理解當前問題並設計軟體以達成對解決方案的共同理解方面非常有幫助。構建應用程式時，DDD將問題描述為領域和子領域。
它會將獨立的步驟或問題領域定義為限界上下文。強調使用通用語言討論問題，並引入許多技術概念，如[實體、值物件和聚合根規則]來具體實現。有時這些技術規則被視為實現DDD的硬性障礙，但最終，人們往往忘記最重要的是將程式碼工件與業務問題保持一致，並使用相同的通用語言。
設計為服務應用程式的限界上下文
我想討論的架構風格與微服務相似。它涉及將單體應用程式拆分為多個獨立的服務應用程式，或從一開始就藉助限界上下文這一DDD的概念來單獨開發它們。
有許多資源突出更細粒度服務的優點，作為微服務敘述的一部分。越來越多部落格討論在向細粒度服務過渡前或過渡期間你應該具備的防護網和可能遇到的陷阱。我將嘗試不重複微服務的好處或為遷移到這種架構而需要的支援元素，而是重點討論如何透過應用領域驅動設計的概念來更好地分離這些服務。
例項
一個借記/信用卡收單領域。這個領域可以（如很多情況下的那樣，不幸地）被實現為一組單體應用程式。之所以有多個應用程式，僅因在不同應用程式中存在一些硬性技術限制（如希望執行批處理過程）。
大多數成功的架構都認識到透過DB整合是一種不好做法，因為它模糊了技術應用程式和業務職責之間的邊界，使業務邏輯洩露到DB，並透過增加應用程式伺服器數量來阻礙水平擴充套件。因此，向更好架構的演進表現為單體應用程式的服務整合。
現在，應用程式之間的邊界變得更清晰了。但正如你所見，仍然存在隱藏的DB互動，這次是在各獨立應用程式內部發生。我稱它們為隱藏的，因為它們通常一開始很難被注意到。隨時間推移，程式碼纏繞會使原本分離的業務流程在人為上聯絡，並在業務開發引入更多摩擦，因為這種共存需要共同部署獨立的功能，可能減緩開發進度。
若你有一個領域模型指導你，領域建模有助識別和分離糾纏在一起的實現。若你還沒現有應用程式的領域模型（這在大多數情況下是真實的），與其透過程式碼來理解不同職責，不如建立一個領域模型並將其對映到手頭的應用程式，可能是更好方法。這不僅節省時間，還可避免陷入細節困境。而且，若業務團隊與開發團隊存在差距（可能是領域模型一開始就不存在的主要原因），討論領域模型並將其與現有應用程式的功能對應起來，有助於彌補這一差距。
設計演進的下一步是將領域邊界分離反映到我們的架構及限界上下文中。一個領域有多個限界上下文，意味著同一領域內可能有多個服務應用程式。
透過合適的領域模型，潛在的拆分點更加清晰，使我們能從更細粒度的應用程式中受益，如獨立釋出和版本控制、純粹的基於能力的服務端點等，大多數這些優點已經在微服務文章中討論過了。雖然許多關於微服務的討論集中在技術中立性和開發紀律（避免/打破單體）上，但對於我們大多數人所處理的應用程式而言，領域和設計層面的考慮同樣具有很高的價值。在轉向微服務架構（藉助領域模型）之後，DDD和更細粒度的服務可以相互協作，共同支撐。
這也將為團隊提供一定程度的獨立性，更精細的服務能力和更解耦的互動，如許多微服務文章中所解釋的那樣。
此外，正如案例信用卡支付收單領域中所見，這不是我們服務可達到的最細粒度分離。相反，這是透過我們的領域知識指導下的最有意義的分離。關鍵不在於服務的規模，而在於業務能力的劃分。我認為這就是許多人所說的“正確的SOA”。
關注我，緊跟本系列專欄文章，咱們下篇再續！
作者簡介：魔都架構師，多家大廠後端一線研發經驗，在分散式系統設計、資料平臺架構和AI應用開發等領域都有豐富實踐經驗。
各大技術社群頭部專家博主。具有豐富的引領團隊經驗，深厚業務架構和解決方案的積累。
負責：
- 中央/分銷預訂系統效能最佳化
- 活動&券等營銷中臺建設
- 交易平臺及資料中臺等架構和開發設計
- 車聯網核心平臺-物聯網連線平臺、大資料平臺架構設計及最佳化
- LLM Agent應用開發
- 區塊鏈應用開發
- 大資料開發挖掘經驗
- 推薦系統專案
目前主攻市級軟體專案設計、構建服務全社會的應用系統。
參考：
- 程式設計嚴選網
本文由部落格一文多發平臺 OpenWrite 釋出！