领域驱动分层架构模型
我们在上文中给大家简单介绍了领域驱动分层架构的组成结构等内容，而本文我们在来了解一下，领域驱动分层架构模型。
用户接口层
Controller:提供较粗粒度的调用接口，将用户请求委派给一个或多个应用服务进行处理
DTO:数据传输的载体，内部不存在任何业务逻辑，我们通过DTO把内部的领域对象与外界隔离。
Mapper:实现DTO与领域对象之间的相互转换和数据交换。
应用层
Event:存放事件相关代码，可以进行事件的发布和处理。事件发布和订阅放在应用层，事件相关的业务逻辑放在领域层。
Service：对多个领域服务或外部应用服务进行封装、编排和组合，对外提供粗粒度的服务。应用服务主要实现服务组合和编排，是一段独立的业务逻辑。
领域层
Aggregate：是Entity、Event、Service、Repository的根目录，聚合内实现高内聚的业务逻辑，可以根据实际项目中业务的聚合名称命名。在聚合内定义聚合根、实体和值对象以及领域服务之间的关系和边界。如果我们的项目需要进行微服务的拆分，那么一个聚合里的内容可以拆分为一个单独的服务。
Entity：用来存放聚合根、实体、值对象以及工厂模式(Factory)相关代码。实体类采用充血模型，同一实体相关的业务逻辑都在实体类代码中实现。跨实体的业务逻辑代码在领域服务中实现。
Event：存放事件实体以及与事件活动相关的业务逻辑代码。
Service：存放领域服务代码。一个领域服务是多个实体组合出来的一段业务逻辑。领域服务封装多个实体或方法后向上层提供应用服务调用。
Repository：存放所在聚合的查询或持久化领域对象的代码，通常包括仓储接口和仓储实现方法。为了方便聚合的拆分和组合，好一个聚合对应一个仓储。
基础设施层
Config：主要存放一些配置相关代码。
Util：其它诸如数据库、缓存、文件，三方类库相关的代码可以在这个目录下建立子目录。
在领域驱动的代码模型中需要注意的是:
分层的概念一定要清晰，明确各层的职责。
聚合的代码边界一定要清晰，聚合之间一定是松耦合低关联的。