建立領域模型步驟

根據提供的信息完善主要業務場景和業務流程；

根據業務流程識別領域事件并按照時序排列；

針對領域事件進行命令識別；

針對領域事件和命令進行聚合和子域的初步識別；

在識別的subdomain中識別實體、值對象、實體間關系、調整聚合關系；

針對領域模型識別限界上下文（Bounded Context）。

?

三原則

Focus on your core domain. Core domain：存在差異性競爭力的業務

Iteratively explore models. 方法：通過實踐和軟件（UML）

speak ubiquitous language. 方法：一種能合作的語言，業務術語（概念）

?

實踐

1.信息

2.業務場景圖&業務流程圖

領域事件

• 業務事件
• 時間序列
• 所有的事件
• 命名：聚合#動詞的過去時

命令

• 來源：
  ```

UI 用戶操作

外部系統觸發

定時任務
```

• 注意：
  ```

cmd:event→1：1，推薦

cmd:event→1：n，可以，盡量避免

cmd:event→n：1，不可以
```

• 命名： 動詞

聚合

• 定義：生命周期相同的領域對象（實體、值對象）的集合。
• 方法：可在cmd和event之間夾出聚合。
  ```

每個聚合都有一個根和一個邊界。

每個聚合選擇其中一個實體作為聚合根，本質是一個實體。

一個actor是一個聚合。

外部通過聚合根訪問聚合內領域對象。

盡量小。
```

實體&值對象

• 來源：領域對象，來源于業務概念。
• 值對象：無id，狀態不可變 DDD中的值對象與C#的struct很像相似，是不是值對象應該使用struct？ 答：struct 作為一種技術選擇，有時候也許可行，但或許更多時候是不可行，比如：struct不能為空，使得不能與領域對象對應。
• 實體：有id，有狀態

限界上下文

• 識別：同一個對象，有時表達的含義不同時，此時可能需要兩個限界上下文。
• 盡量大
• 跨限界上下文訪問：RPC、REST、MQ
• 盡量使子域和限界上下文對應。

技術對應

• 子域、限界上下文對應項目（微服務的話，對應應用服務）
• 聚合對應actor（或者對象類）
• 推薦盡量一個實體對應一個聚合對應一個actor
• 應用服務對應Controller API
• 領域事件對應事件
• 實體反映在數據庫表結構
• Repository類似DAO
• DTO在應用層

RESTful架構下的API設計

1. 從命令出發

2. 從資源出發

RESTful架構下“資源”（resource）識別至關重要。在整個DDD建模中，聚合和實體都是我們抽象資源的重要入手點。

這種方法比較適合識別Domain層的API設計。

3. 從業務流出發

API 最終都要滿足業務的需求，所以也有API設計方法從流程節點的分析出發。

這種設計方法更適合Application層的API設計

4. 定義關鍵詞動詞描述

（如果有不正確的地方，希望童鞋指正）

?

（如果有不正確的地方，希望童鞋指正）

?

?

?

?

?

?

?

?

?

?

?

轉載于:https://www.cnblogs.com/CharlesZHENG/p/10205258.html

總結

以上是生活随笔為你收集整理的20190101.DDD笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

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