建立领域模型步骤
- 根据提供的
信息完善主要业务场景和业务流程； - 根据业务流程识别
领域事件并按照时序排列； - 针对领域事件进行
命令识别； - 针对领域事件和命令进行
聚合和子域的初步识别； - 在识别的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设计