一、前言

二、領域、子域、限界上下文

1.領域

2.子域

核心域、支撐子域、通用子域

3.限界上下文

（1）邊界
限界上下文是一個顯示的邊界，領域模型邊存在於這個邊界之內。
在邊界內，每一個概念模型，包括其屬性和操作，都具有特定的含義。

（2）概念命名
在一個上下文中，團隊通常根據通用語言來命名某個概念。

比如兩個銀行上下文，一個用於支票賬戶，一個用於儲蓄賬戶。在支票上下文中，我們不必使用 checking account ，也不必在儲蓄上下文中使用 saving account ，兩個概念都可以使用賬戶 account 來表示。

4.問題空間和解決方案空間

在領域中還同時存在著問題空間和解決方案空間

• 問題空間
  問題空間是領域的一部分，對問題空間的開發將產生一個新的核心域。對問題空間的評估應該同時考慮已有子域和額外所需子域。
  因此， 問題空間是由戰略核心域及其支撐子域組成

• 解決方案空間
  解決方案空間包括一個或多個界限上下文，即一組特定的軟體模型。

三、上下文對映圖

兩種表示方式：

• 簡單框圖
• 原始碼實現

1. 9種DDD組織和整合關係

• 開放主機服務
• 釋出語言
• 防腐層

2.示例圖

四、架構

1. 一個成功案例的架構演進

1.1 SAAS的訂閱模型

1.2 六邊形架構

1.3 SOA

通過SOA的方式來聚合資料

1.4 CQRS架構

1.5 事件驅動架構

使用管道和過濾器模式實現

1.6 優化1

將管道和過濾器分佈化和並行化，這需要加入長時處理過程，有時也加入Sagas.

1.7 優化2

跟蹤對系統的每一次改變，採用事件源（Event Sourcing）

2. 分層架構

2.1 分層架構圖

分層架構模式被認為是所有架構的始祖。

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

• 使用者介面層 : User Interface
• 應用層：Application Layer
• 領域層：
• 基礎設施層：Infrastructure Layer

2.2 分層架構原則

分層架構的一個重要的原則是：每層只能與位於其下方的層發生耦合

2.3 分層架構種類

分層架構分類：

• 嚴格分層架構
  某層只能與直接位於其下方的層發生耦合。
• 鬆散分成架構
  允許任意上方層與任意下方層發生耦合。由於使用者介面層和應用服務通常需要與基礎設施打交道，許多系統都是基於鬆散分層架構的。

2.4 使用者介面

使用者介面只用於處理使用者顯示和使用者請求，可對使用者輸入進行校驗，不應該包含領域或業務邏輯。

如果使用者介面使用了領域模型中的物件，那麼此時的領域物件僅限於資料的渲染展現。在採用這種方式時，可以使用展現模型（Presentation Model），對使用者介面和領域模型進行解耦。

由於使用者可能是人，也可能是其他的系統，因此有時使用者介面層將採用開放主機服務的方式向外提供API

2.5 應用服務

應用服務（Application Service）位於應用層中。

應用服務和領域服務（DomainService）是不同的，因此領域邏輯不應該出現在應用服務中。

應用服務可以用於持久化事務和安全認證，或者向其他系統傳送基於事件的訊息通知，另外還可以用於建立郵件以傳送給使用者。

應用服務本身並不處理業務邏輯，但它卻是領域模型的直接客戶。

應用服務是很輕量的，它主要用於協調對領域物件的操作，比如聚合

聚合的最佳實踐：

當需要建立新的聚合時，應用服務應該使用工廠或聚合的建構函式來例項化物件，然後採用資源庫對其持久化。應用服務還可以呼叫領域服務來完成和領域相關的任務操作，但此時的操作應該是無狀態的。

儲存和轉發事件：p106

資源庫介面實現放在應用層中：
在分層架構中，領域層或多或少地需要使用基礎設施層。這裡我並不是說核心的領域物件會直接參與其中，而是說領域層中的有些介面實現依賴於基礎設施層。比如資源庫介面的實現需要基礎設施層提供的持久化機制。

還有更好的方法，參見下文的依賴倒置原則。

2.6 基礎設施

2.7 依賴倒置原則

3.六邊形架構（埠與介面卡）