1.業務架構是什么

隨著業務的發展，我們面臨的業務場景也越來越復雜，而為了解決這些復雜的業務問題，我們的實現方案也越來越復雜，而復雜度就會帶來理解、維護、迭代的難度增加。擺在我們面前的問題，就是如何在實現復雜業務時，控制好系統的復雜度。

?

業務架構的核心目的，是控制系統的復雜度。通過業務架構，來傳遞規范與約束。引導開發人員在實現業務功能時，進行合理的業務問題分解，結構化、抽象化設計，保證系統的可維護性與可讀性，延緩系統腐化速度。

?

2.分層架構

傳統的三層架構分為表現層、業務邏輯層、數據訪問層，各層之間通過接口交互，通過Model來傳遞數據。這種三層架構非常簡單，基本沒有開發門檻，往往適用于功能簡單的單體應用。當業務較復雜，對穩定性和擴展性有一定要求時，我們往往會采用微服務分層架構。與傳統的三層架構相比，微服務架構里將業務邏輯層拆分為兩部分，一部分是針對業務場景的業務網關層，一部分是針對業務邏輯的業務服務層。我們往往將邏輯功能放在業務服務層，實現業務的隔離與復用。

微服務分層架構能滿足大多數業務，這也是我們最常見的業務架構之一，但是它也依然存在問題。業務網關層和業務服務層之間的邊界，需要開發人員理解并遵守分層規范才行，但是實際開發過程中大家的理解不一致，經常會出現所有邏輯實現都在業務網關層、業務服務層只提供數據，以及出現所有邏輯實現都在業務服務層、業務網關層只提供調用入口現象。前者導致服務層“太瘦”，上層復用時相關業務邏輯需要重新實現一遍；后者導致服務層“太胖”，復用性較差甚至無法復用；

?

分層架構的優點之一就是簡單、約束少，可以在很短時間內實現簡單業務功能，入門門檻低。開發人員只需要面向UI設計相應數據庫表結構，在封裝相應CURD接口就能快速實現一個功能。這也是分層架構如此普及的原因之一。但是，在它帶來便捷的同時，它也帶來了一些不利的因素，其中之一就是開發人員缺乏對業務場景的深度理解，缺乏對該類問題的抽象思考。當再次遇到同類功能時，都需要這么重復做一遍。長此以往，重復的表結構/字段會很多，相似的代碼模塊也會很多，十分不利于系統的升級維護。

?

3.DDD

DDD（領域驅動設計）是用來解決系統復雜性的方法論。DDD是一套系統性的設計思想，它在戰略設計層面上，提出了領域、子域、限界上下文，來指導將一個大系統拆分為多個子系統。它在戰術設計層面上，提出了實體、值對象、聚合根、工廠、基礎設施、領域服務、領域事件等概念，來指導領域模型的實現落地。它是一種抽象思想，并不是一種具體的架構。在業務落地實現時，開發人員需要深入思考領域知識和業務知識，找到各個層次的邊界。同時，分層內每一層次間的命名應符合統一規范，層次之間的交互應遵從最少知識原則，保證分層的獨立性，解耦依賴。在做領域模型設計時，領域內部要聚焦在這個域自身功能上，設計時重點思考領域應該具備的能力，而不是面向調用方。通過領域模型可以提升設計過程的規范，有助于提高開發人員的架構設計能力，提升系統的可讀性、復用性和擴展性。

基于領域模式實現功能時，經常遇到的問題之一，是哪些邏輯應該放在領域內，如果把所有業務邏輯都放到領域內，那過度膨脹的領域就失去了領域自身表達的意義。我們在實踐中，通常會先將業務邏輯拆分為原子的功能點和控制流程，將明確屬于領域內的邏輯合并，將不明確的功能點放在應用層，在后續迭代中再根據業務來沉淀模型能力。

在分層設計實現中，我們需要將領域邏輯與業務場景流程控制分離。在領域層來實現核心業務功能，在應用層，通過流程控制聚合各個領域實現特定業務場景，同時在應用層實現不屬于領域內的業務場景細節邏輯。流程控制方面需要結合業務，原則上以簡潔實用為主，保證既能滿足業務功能，又能保持擴展性和可讀性。在我們業務中，大部分業務場景是基于領域能力組合實現，少部分業務場景我們引入了FSM(有限狀態機)、輕量規則引擎、Pipeline模式等；

誠然DDD有很多優勢，但是我們在實踐和持續迭代過程中也遇到一些問題。最明顯的問題是DDD對開發人員要求較高，需要開發人員對領域模型和業務知識有較深入的思考與理解，才能設計出符合領域規范的實現方案。在理解不充分時，會出現強行套概念現象，最終的實現往往會變成“四不像”，不僅不能合理表達領域的能力，而且還會因為未正確實現約束導致代碼混亂。

4.適合當前業務的架構

在我們已有的微服務架構中，我們嘗試著以一種更輕量級的領域設計來融合到微服務業務架構中。通過領域模式的核心思想，來管理業務域的核心邏輯，在概念上保留領域對象、基礎設施、領域服務、領域事件，同時領域對象采用貧血模型，通過領域方法來描述領域能力，邏輯功能高度內聚。同時，在領域服務層，我們分離讀和寫，只有寫服務依賴領域能力來實現核心的狀態變更，讀服務直接基于基礎設施層來提供能力。這種模式下形成的架構如下：

通過這樣的分層，我們在層次間的依賴上面，保持了足夠的靈活性；而在核心的業務邏輯上，也具備領域能力的高度內聚，保證了一定的復用性和擴展性。同時，也降低了對開發人員的要求，讓對領域模型理解不深的人員也能保證一定的完成質量。

5.總結

業務架構并沒有所謂的通用方案，它跟業務形態，業務發展所處階段息息相關，只有適合自身業務的架構才是最好的架構。

總結

以上是生活随笔為你收集整理的关于业务架构的一些思考与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。