1.3 分層架構演進

1.3.1 傳統四層架構

將領域模型和業務邏輯分離出來，並減少對基礎設施、用戶界面甚至應用層邏輯的依賴，因為它們不屬業務邏輯。將一個夏雜的系統分為不同的層，每層都應該具有良好的內聚性，並且只依賴於比其自身更低的層。

傳統分層架構的基礎設施層位於底層，持久化和消息機制便位於該層。這裡的消息包含

• MQ消息
• SMTP
• 文本消息(SMS)

可將基礎設施層中所有組件看作應用程式的低層服務，較高層與該層發生耦合以復用技術基礎設施。即便如此，依然應避免核心的領域模型對象與基礎設施層直接耦合。

1.3.2 改良版四層架構

傳統架構的缺陷

DDD初創開發團隊發現，將基礎設施層放在最底層存在缺點，比如此時領域層中的一些技術實現就很困難：

• 違背分層架構的基本原則
• 難以編寫測試用例

何解？使用依賴反轉設計原則：低層服務（如基礎設施層）應依賴高層組件（比如用戶界面層、應用層和領域層）所提供的介面。

應用依賴反轉原則

• 依賴反轉原則後的分層方式：基礎設施層在最上方，可實現所有其他層中定義的介面

依賴反轉原則真的可以支持所有層嗎？有人認為依賴反轉原則中只存在兩層：最上方和最下方，上層實現下層定義的抽象介面。因此上圖的基礎設施層將位於最上方，而用戶介面層、應用層和領域層應作同層且都位於下方。對此大家可保留自己意見。

2 各層職責

2.1 用戶介面層

一般包括用戶介面、Web 服務等。

只處理用戶顯示和用戶請求，不應包含領域或業務邏輯。有人認為，既然用戶介面需驗證用戶輸入，就無可避免應該包含業務邏輯。事實上，用戶介面所進行的驗證和對領域模型的驗證不同：對那些粗製濫造且只面向領域模型的驗證行為，應該予以限制。

如果用戶介面使用了領域模型中的對象，那麼此時領域對象僅限於數據渲染展現。在採用這種方式時，可使用展現模型對用戶介面與領域對象進行解耦。由於用戶可能是人，也可能是其他系統，有時用戶介面層將採用開放主機服務的方式向外提供API。用戶介面層是應用層的直接用戶。用戶介面層在於前後端調用的適配。若你的微服務要提供服務給很多外部應用，而對每個外部應用的入參出參都不同，你不可能開發一堆一對一的應用服務，這時Facade介面就起到了很好的作用，包括DO和DTO對象的組裝和轉換。

2.2 應用層

主要包含應用服務，理論上不應有業務規則或邏輯，而主要是面向用例和流程相關的操作。

• 應用層位於領域層之上，因為領域層包含多個聚合，所以它可協調多個聚合服務和領域對象完成服務編排和組合，協作完成業務。
• 應用層也是微服務間的交互通道，它可調用其它微服務，完成微服務間的服務組合和編排。

開發設計時，不要將本該放在領域層的業務邏輯放到應用層。因為龐大的應用層會使領域模型失焦，時間一長，微服務就會退化為MVC架構，導致業務邏輯混亂。

應用服務是在應用層，負責

• 服務的組合、編排、轉發、轉換和傳遞，處理業務用例的執行順序以及結果的拼裝，以粗粒度服務通過API網關發佈到前端
• 安全認證
• 許可權校驗
• 事務控制
• 發送或訂閱領域事件

2.3 領域層

主要包含聚合根、實體、值對象、領域服務等領域模型中的領域對象。

實現核心業務邏輯，通過各種校驗保證業務正確性。領域層主要體現領域模型的業務能力，它用來表達業務概念、業務狀態和業務規則。

領域模型的業務邏輯主要由實體和領域服務實現：

• 實體採用充血模型 實現所有與之相關的業務功能。

實體和領域服務在實現業務邏輯上不是同級，當領域中的某些功能，單一實體或值對象無法實現，就會用到領域服務，它可組合聚合內的多個實體或值對象，實現複雜業務邏輯。

2.4 基礎層

為其它各層提供通用技術基礎服務：

• 三方工具
• 驅動
• MQ
• API網關
• 文件
• 緩存
• DB 最常用的

基礎層包含基礎服務，它採用依賴反轉，封裝基礎資源服務，實現應用層、領域層與基礎層解耦。

MVC架構由於上層應用對DB強耦合，很多公司在架構演進最怕換DB，一旦更換，可能需重寫一堆代碼。但採用依賴反轉，應用層即可通過解耦保持獨立核心業務邏輯。當DB變更，只需更換DB基礎服務。

作者|Java小旋風

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Understanding-the-Evolution-of-DDD-Layered-Architecture-in-One-Article.html