mzn458的博客

infrastructure(基础层)： 主要存放与基础资源服务相关的代码，为其他各层提供的通用技术能力，第三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层 目录中。主要有config和until两个子目录 config：主要存放配置相关代码 until：主要存放开放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库和通用算法等基础代码，可以为不同的资源建立不同 的子目录 如果在多个微服务中都存在一些通用组件、接口、方.

domain(领域层)： domain层下的目录结构是按照DDD设计的模型来做映射的，其中在DDD建模中的每一个聚合目录构成，每一个聚合是一个独立的业务单元，多个聚 合共同实现领域模型的核心业务逻辑 代码模型包括entity、vo、event、repository、和service五个子目录 service目录结构下 aggregate(聚合)： 是聚合目录的根目录,可以按实际项目的聚合根名称+aggregate结尾来命名，如.

application(应用层）： 应用层主要是向上为接口层提供统一的应用服务，向下对领域层进行领域层的领域服务进行重组、编排和组合的功能。应用服务层也可以直接访问基 础设施层的接口来进行应用编排，但是不能在应用层做领域相关的业务逻辑处理，只能做针对前端应用的业务逻辑处理，避免领域层的领域业务退化 将DDD退化为传统的MVC三层架构。应用层主要目录结构包括（event和service)。 event(事件）:主要存放事件相关代码，其中包括(publish 和 subscri.

interfaces(用户接口层)： 用户接口层是为前端应用提供restful或RPC请求的访问接口，在该层中主要是实现前端的业务逻辑，对前端业务数据的组装和封装，不对领域业务 逻辑实现，所有的领域业务逻辑都由用户都由该层封装后分配给一个或多个应用层服务来实现。 interfaces(用户接口层)目录结构包括：assember、dto、facad三个子目录 assember： 实现DTO与DO领域对象之间的相互转换和数据交换。有时前端的数据dto与传到领域服务.

DDD的代码模型是按照严格分层进行设计的，主要包括，interface(接口层)、application(应用服务层)、domain(领域层)、infrastructure(基础层)进行划分，由于采用了严格的分层架构，不允许进行跨层调用，调用逻辑严格按照以下规则进行；interface(接口层)： 向上提供前端业务接口，向下只能调用application(应用服务层)，infrastructure(基础层)、不允许跨层调用domain(领域层)的相 .