20190101.DDD笔记

建立领域模型步骤

1. 根据提供的信息完善主要业务场景和业务流程；
2. 根据业务流程识别领域事件并按照时序排列；
3. 针对领域事件进行命令识别；
4. 针对领域事件和命令进行聚合和子域的初步识别；
5. 在识别的subdomain中识别实体、值对象、实体间关系、调整聚合关系；
6. 针对领域模型识别限界上下文（Bounded Context）。

   三原则

7. Focus on your core domain.

   Core domain：存在差异性竞争力的业务
   

8. Iteratively explore models.

   方法：通过实践和软件（UML）
   

9. speak ubiquitous language.

   方法：一种能合作的语言，业务术语（概念）
   

   实践

   1.信息
   
   2.业务场景图&业务流程图
   
   

10. 领域事件

• 业务事件
• 时间序列
• 所有的事件
• 命名：聚合#动词的过去时

1. 命令

• 来源：
  ```

1. UI 用户操作
2. 外部系统触发
3. 定时任务
   ```

• 注意：
  ```

1. cmd:event→1：1，推荐
2. cmd:event→1：n，可以，尽量避免
3. cmd:event→n：1，不可以
   ```

• 命名：

  动词
  

1. 聚合

• 定义：生命周期相同的领域对象（实体、值对象）的集合。
• 方法：可在cmd和event之间夹出聚合。
  ```

1. 每个聚合都有一个根和一个边界。
2. 每个聚合选择其中一个实体作为聚合根，本质是一个实体。
3. 一个actor是一个聚合。
4. 外部通过聚合根访问聚合内领域对象。
5. 尽量小。
   ```
6. 实体&值对象

• 来源：领域对象，来源于业务概念。
• 值对象：无id，状态不可变

  DDD中的值对象与C#的struct很像相似，是不是值对象应该使用struct？
  答：struct 作为一种技术选择，有时候也许可行，但或许更多时候是不可行，比如：struct不能为空，使得不能与领域对象对应。
  

• 实体：有id，有状态

1. 限界上下文

• 识别：同一个对象，有时表达的含义不同时，此时可能需要两个限界上下文。
• 尽量大
• 跨限界上下文访问：RPC、REST、MQ
• 尽量使子域和限界上下文对应。

1. 技术对应

• 子域、限界上下文对应项目（微服务的话，对应应用服务）
• 聚合对应actor（或者对象类）
• 推荐尽量一个实体对应一个聚合对应一个actor
• 应用服务对应Controller API
• 领域事件对应事件
• 实体反映在数据库表结构
• Repository类似DAO
• DTO在应用层

RESTful架构下的API设计

1. 从命令出发

2. 从资源出发

RESTful架构下“资源”（resource）识别至关重要。在整个DDD建模中，聚合和实体都是我们抽象资源的重要入手点。

这种方法比较适合识别Domain层的API设计。

3. 从业务流出发

API 最终都要满足业务的需求，所以也有API设计方法从流程节点的分析出发。

这种设计方法更适合Application层的API设计

4. 定义关键词动词描述

 

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

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