domain(领域层)：
domain层下的目录结构是按照DDD设计的模型来做映射的，其中在DDD建模中的每一个聚合目录构成，每一个聚合是一个独立的业务单元，多个聚
合共同实现领域模型的核心业务逻辑
代码模型包括entity、vo、event、repository、和service五个子目录
service目录结构下
aggregate(聚合)：
是聚合目录的根目录,可以按实际项目的聚合根名称来命名，如：领域建模中的Person聚合根，可以命名为
person来命名该领域的Person聚合，在将来由于业务或性能需要对该领域进行拆分时，可以将整个聚合移除，形成一个新的领域。
entity(实体)：
存放聚合根、实体和值对象等相关代码，实体中除了业务属性还有业务行为，也就是实体类中的方法，形成充血实体。如果在领域模型
中包含的实体较多，可以在entity(实体)下增加多个子目录，方便后续代码维护和查找。实体子目录命名按照实体名称为子
目录命名。实体的文件命名以实体名称命名。如：Person实体，文件命名为Person.java
vo(值对象):
值对象在实体子目录下的vo目录中，值对象命名以值对象实体名称。
event(事件)：
它存放事件相关的实体以及与事件活动相关的业务逻辑代码，如果设计到事件总线，如消息队列等事件的发布与订阅时，不建议将事件
发布与订阅放到领域层，将相关业务提升到应用服务层中的事件目录中，有应用服务层来调用领域服务，进行相关的业务编排和组合。
repository(仓储)：
它存放仓储服务相关代码，仓储模式通常包含仓储接口和仓储实现服务。他们一起完成聚合内DO领域对象的持久化，或基于聚合根ID查
询，完成聚合内实体和值对象等DO领域对象的数据初始化。另外仓储目录还会有持久化对象PO，以及持久化实现逻辑相关代码，如DAO
等，在仓储设计时有一个重要原则，就是一个聚合只能有一个仓储。
注意：按照DDD分层架构，仓储本应该属于基础层，但为了在微服务架构演进时保证聚合代码重组的便利，这里将仓储相关代码也放到
了领域层的聚合目录中因为聚合和仓储总是一对一的关系，将领域模型和仓储的代码组合在一起后，就是一个包含了领域逻辑和基础数
据处理逻辑的聚合代码单元。一旦领域模型发生变化，当聚合需要在不同的限界上下文或微服务之间进行代码重组时，我们就可以以聚
合代码包为单元，进行整体拆分或迁移，轻松实现微服务架构演进。虽然领域相关的业务代码和基础资源处理相关代码都在一个聚合代
码目录下，但是聚合的核心业务逻辑仍然是通过调用仓储接口来访问基础资源的仓储实现处理逻辑，所有这样不会影响业务逻辑的依赖
倒置设计。
repository(仓储)代码子目录包括：facade、persistence、po、dao
facade:
定义仓储的接口
persistence：
定义仓储接口的实现
po：
定义po对象实体
dao：
定义数据持久化的方法
service(领域服务)：存放领域服务，工厂服务等相关代码，领域服务可以封装多个实体或方法供上层应用服务调用。领域服务有两种，一种
为在DDD建模时，模型中的服务，这种服务是由于需要该领域内的多个聚合组合完成的服务。另一种为单个聚合需要提供对外服务，由
于严格分层架构的需要，应用层不能直接调用entity(实体)中的方法,因此需要通过领域服务层将entity(实体)中的方法进行封装，
提供给应用服务层调用。目录结构如下：
factory:
聚合内的聚合根、实体和值对象的依赖关系比较复杂，这种对象的创建会增加聚合根构造函数的代码实现的复杂度，这时可以增加
factory目录，将复杂对象的创建放到该目录中，factory目录放在领域聚合的,文件命名以实体名称+Factory
domainservice:
存储领域模型中的领域事件
entityservice:
存储实体对象中需要对外提供服务的相关事件的封装
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
