将领域对象映射到微服务代码模型中。DDD强调
- 先构建领域模型
- 然后设计微服务
以保证领域模型和微服务的一体性。但在构建领域模型时，我们往往是在业务视角，并且有些领域对象还带业务语言。我们还需要将领域模型作为微服务设计的输入，对领域对象进行设计和转换，让领域对象与代码对象建立映射关系。
领域对象的整理
完成微服务拆分后，领域模型的边界和领域对象就基本确定了。
第一个工作就是，整理事件风暴过程中产生的各个领域对象，比如：聚合、实体、命令和领域事件，将这些领域对象和业务行为记录到下面表格。
这张表格包含：领域模型、聚合、领域对象和领域类型四维。
一个领域模型会包含多个聚合，一个聚合包含多个领域对象，每个领域对象都有自己的领域类型。领域类型主要标识领域对象的属性，比如：聚合根、实体、命令和领域事件等类型。
从领域模型到微服务的设计
从领域模型到微服务落地，还需进一步设计和分析。事件风暴中提取的领域对象，还需经过用户故事或领域故事分析，以及微服务设计，才能用于微服务系统开发。
主要关注内容如下：
- 分析微服务内有哪些服务？
- 服务所在的分层？
- 应用服务由哪些服务组合和编排完成？
- 领域服务包括哪些实体的业务逻辑？
- 采用充血模型的实体有哪些属性和方法？
- 有哪些值对象？
- 哪个实体是聚合根等？
- 最后梳理出所有的领域对象和它们之间的依赖关系，我们会给每个领域对象设计对应的代码对象，定义它们所在的软件包和代码目录。
这个设计过程建议参与的角色有：DDD专家、架构师、设计人员和开发经理。
领域层的领域对象
事件风暴结束时，领域模型聚合内一般会有：聚合、实体、命令和领域事件等领域对象。
完成故事分析和微服务设计后，微服务的聚合内一般会有：聚合、聚合根、实体、值对象、领域事件、领域服务和仓储等领域对象。
这些领域对象如何得来？
设计实体
大多数情况下，领域模型的业务实体与微服务的数据库实体一一对应。但某些领域模型的实体在微服务设计时：
- 可能会被设计为多个数据实体
- 实体的某些属性被设计为值对象
比如分析个人用户时，还要有地址、电话和邮箱等实体，它们被聚合根引用，不易在领域建模时发现，需在微服务设计过程中识别和设计出。
在分层架构里，实体采用充血模型，在实体类内实现实体的全部业务逻辑。这些不同的实体都有自己的方法和业务行为。
比如地址实体有新增和修改地址方法，邮箱实体有新增和修改银行账号的方法。
实体类放在领域层的Entity目录。
找出聚合根
聚合根源于领域模型，在个人客户聚合里，个人客户这个实体是聚合根，它负责管理地址、电话及邮箱的生命周期。
个人客户聚合根通过工厂和仓储模式，实现聚合内地址、邮箱等实体和值对象数据的初始化和持久化。
聚合根是一种特殊的实体，它有自己的属性和方法。聚合根可实现聚合间的对象引用，还可引用聚合内的所有实体。聚合根类放在代码模型的Entity目录结构下。聚合根有自己的实现方法，比如生成用户编码，新增和修改用户信息。
