前边两篇，我们讲述为什么用DDD？DDD如何做好需求梳理？DDD如何在系统的层面拆分为粗细粒度合适微服务，以及微服务的架构划分。也就是我们经常说的自顶向下的拆分，现在我们将要做的功能具体拆分到具体的服务上了，也有了菱形架构、四边形架构等骨架，那么接下来就需要我们进行领域的建模了，也就是传统软件设计中的详细设计了。先看下，这个阶段的重要点：
好，先说一下，我们传统的软件详细设计都是怎么做的？ER图进行业务抽象建模，根据ER图进行数据设计，功能流程图、时序图，数据流图，类图、状态图等通过抽象分析设计表、流程、数据扭转、状态、抽象接口类方法等方面，进行详细设计，进而有了可以编码的“说明书”。
而DDD呢？其实一些进行分析抽象设计的方法是公用的，我一直觉得每种方式方法论都有其的优势与劣势，我们不要将其边界划分的太割裂，要善于取其精华去其糟粕。例如我认为流程图、时序图、思维导图等是非常好用的工具，在任何地方都可以去善于应用的。好，接下来我们看下DDD中领域建模几个核心点：
一，实体（entity）、值对象(value object)
实体：实体是我们统一语言中，根据现实生活、具体业务进行抽象的，具有唯一标识，可变性，具有生命周期等特性。而且DDD中的实体，经常会设计成充血模型（充血、贫血模型可参考《充血模型VS贫血模型》）。和现实对比一下：人（类）有手、脚、嘴、鼻子……（属性），可以拿东西、踢足球、吃饭、闻气味（方法能力），不像传统的类，只有get、set方法，而具体的功能方法都在业务类中。
值对象：通过对象属性值来识别对象，它将多个相关属性组合为一个概念整体。其实就是在业务中用来传输一些属性值的合体。没有生命周期，不可变、不具有唯一标识等。
举个例子：在用户下单购买物品时，订单就是一个实体，根据统一语言抽象为订单，具有唯一订单号，进行下单过程订单的某些属性会不停的改变，订单完成以后生命周期也就结束了，其中订单的各种变化，都已在实体中具有其对应的功能方法（充血）；而在统计业务中，单笔订单就可以设计为值对象，主要是为了传输其属性值，值不可变，没有生命等。也就是实体和值对象不是绝对的，而且在不同的场景身份会进行相应的改变。
最后，想聊下，为什么DDD推崇实体实现用充血模型呢？个人感觉是：更符合现实生活，更加容易理解。当然更重要的内聚更高，从而更易扩展，也就更易应对业务需求的变化了……
二，聚合（Aggregate）、聚合根（AggregateRoot）
聚合（Aggregate）,实体和值对象其实个体，就像现实生活一样，我们有个人有团体，而聚合就类似团体，而聚合根可以理解为其领导（或者和外边打交道的角色）。聚合其实就是为了某个业务，抽象的高内聚的边界。
如何设计聚合呢？
1，采用事件风暴；
2，从众多实体中选出适合作为对象管理者的根实体，也就是聚合根；
3，根据业务单一职责和高内聚原则，找出聚合根关联的所有紧密依赖的实体和值对象；
4，在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型；
5，多个聚合根据业务语义和上下文一起划分到同一个限界上下文内；
聚合一些设计原则：
1，在一致性边界内建模真正的不变条件（抽象业务）
2，尽量小的聚合（善于管理、更容易应对变化）
3，通过唯一标识引用其他聚合（低耦合）
4，聚合之间使用最终一致性（领域事件-低耦合）
看下经常用的几种对象：
1，数据持久化对象 PO(PersistentObject)，与数据库结构一一映射，是数据持久化过程中的数据载体。
2，领域对象 DO（DomainObject），微服务运行时的实体，是核心业务的载体。
3，数据传输对象 DTO（Data TransferObject），用于前端与应用层或者微服务之间的数据组装和传输，是应用之间数据传输的载体。
4，视图对象 VO（ViewObject），用于封装展示层指定页面或组件的数据。
三，领域服务、领域事件
领域服务：将抽象的业务进行封装实体、值对象、聚合等对外提供的服务Domain Service。
领域事件：领域之间的异步交互业务处理，我们常用的mq处理机制publish和 subscribe。
领域建模，就是在上篇的大的划分架构基础上，对具体的业务进行设计，抽象出实体、值对象，组合出聚合根，对外暴露出服务，设计出事件异步处理功能。从而是微服务达到有架构有肉的饱满的目的。进而完成微服务的实现。
其实在这里想说几点：1，抽象是核心；2，自顶向下的拆分是方法；3，高内聚低耦合是追求；4，易扩展、易复用，易维护是目的。