TechNomads

分层领域模型命名约定

DDD分层领域模型规约：

• DTO（Data Transfer Object ）：Thrift/pigeon 接口定义对象命名方式，命名方式XxxDTO
• DO（Data Object）：持久层对象命名方式。命名方式XxxDO
• Entity（实体）：代表一个领域实体。命名方式XxxEntity
• ValueObject（值对象）：代表一个领域值对象。命名方式XxxValue

应用层

1.【强制】禁止在应用层写任何领域逻辑，仅负责协调领域模型对象，通过它们的领域能力来组合完成一个完整的应用目标

2.【强制】与横切关注点相关的内容应该放在应用层

3.【强制】thrift接口参数校验属于横切关注点，应该放在应用服务来做

实体

1.【强制】实体对象的命名以Entity结尾。比如UserEntity、CompanyEntity

2.【推荐】Entity<->DO转换建议使用Mapstruct（参考本文【mapstruct对象转换示例】），除非有足够的理由不使用。

3.【推荐】实体尽量使用充血模型。属于实体的行为必须放在实体中，不能放在聚合根中，否则会造成实体贫血

4.【强制】如果主体拥有唯一标识，业务也要关注主体的状态变化，那么它应该被定义为实体

值对象

1.【推荐】应该尽量使用值对象来建模而不是实体对象

2.【强制】当只关心某个对象的属性时，该对象必须定义成一个值对象

3.【强制】值对象的命名规则为 name + Value

说明，比如AddressValue、DescriptionValue、DiscountValue，表示值对象

聚合根

1.【强制】在一个事务中只修改一个聚合实例。如果在单个事务中修改多个聚合，意味着选定的一致性边界是错误的。

2.【推荐】每次客户请求应该只在一个聚合实例上执行一个命令方法

3.【推荐】尽量将聚合建模成单个实体-根实体

领域服务

1.【强制】确保领域服务是无状态的。

2.【参考】当领域中的某个操作过程或转换过程不是实体或是值对象的职责时，此时我们应该将该操作放在领域服务中

3.【强制】领域服务的命名采用【服务名】+ Service的方式，不能为领域服务定义接口

4.【强制】明显属于实体对象或者值对象的行为不应放在领域服务中，否则会导致领域对象贫血

领域事件

1.**【推荐】**领域事件的命名采用【领域】+ Event的方式

基础设施层

1.【强制】thrift接口应该放在基础设施层

2.【强制】领域层只定义资源库的行为（Interface），实现在基础设施层

3.【强制】接2，领域层定义的资源库的Interface使用领域层对象，对象转换在基础服务层完成

4.【强制】Remote的实现必须放在基础设施层

5.【强制】repository的实现层入参出参应该是业务层对象（值对象或者实体），不能直接使用DO

工厂

1.【强制】每个创建方法都是原子的。

2.【推荐】Factory应该被抽象为所需的类型，而不是所要创建的具体类

其他

1.【强制】大段的对象转换逻辑，必须重构成方法

有疑问请参考：4.DDD工程实践参考文档