參考：https://insights.thoughtworks.cn/ddd-in-distributed-system/ 在分布式系統中使用DDD
DDD 的四層架構： 接入層、應用層（Application Servier）、領域層（Domain Service）、基礎設施層
- 接入層：在復雜度不高的情況下，我們往往把接入層和應用層合並部署，
- 關心視圖和對外的服務，Restful、頁面渲染、websocket、XMPP 連接等
- 如果沒有多種接入方式，可以和應用層合並
- 對應到分布式系統中的網關、BFF、前台等概念
- 只產生接入異常，例如數據校驗，對應 HTTP 狀態碼 400、415 等
- 一個應用可以有多個接入層
- 接入層做和業務規則無關的 bean validation 驗證
- 准單體系統下，按照連接方式分包
- 應用層：
- 關心處理完一個完整的業務
- 該層只負責業務編排，對象轉換，實際業務邏輯由領域層完成
- 不關心請求從何處來，但是關心誰來、做什么、有沒有權限做
- 集成不同的領域服務解決問題
- 最終一致性（最終一致性對業務有侵入）事務放到這層
- 對應到分布式系統中的中台等概念
- 方法級別的功能權限控制放到這層
- 只產應用異常，對應 HTTP 狀態碼 403、401
- 准單體系統下，按照應用划分模塊
- 領域層：
- 不關心場景，關心模型完整性和業務規則
- 不關心誰來，不關心場景完整的業務，關心當前上下文的業務完整
- 強一致性事務放到這層，聚合的事務是 "理所當然的"
- 對應到分布式系統中的 domain service、后台等概念
- 領域層做業務規則驗證
- 產生業務規則異常，例如用戶退款條件不滿足，對應狀態碼 412、419 等
- 數據權限放到這層（比如只允許刪除自己創建的商品），因為數據權限涉及業務規則
- 准單體系統下按照上下文分包，上下文之間調用必須走領域 domain service，目的就是解耦
- 上下文中分聚合，聚合根要足夠小，只允許聚合根擁有對應的 domain service
- 根據業務情況，參考反范式理論，跨上下文使用值對象做必要的數據冗余
- 基礎設施層：技術設施層並不是指 MySQL、Redis 等外部組件，而是外部組件的適配器，Hibernate、Mybatis、Redis Template 等，因此在 DDD 中適配器模式被多次提到，基礎設施層往往不能單獨存在，還是要依附於領域層。技術設施層的適配器還包括了外部系統的適配
- 關心存儲、通知、第三方系統等外部設施（防腐層隔離）
- 如果使用自動化的 ORM，這層可以在一定程度上省略
- 基礎設施異常，應丟出內部異常，對應狀態碼 500
- 准單體系統下按照 adapter 分包
- 基礎設施的權限由配置到應用的憑證控制，例如數據庫、對象存儲的憑證，技術設施層不涉及用戶的權限