参考极客时间《DDD实战》
三层架构
传统的三层架构主要分为业务接口层、业务逻辑层、数据访问层
业务接口层：主要是API的定义，包括资源路径定义、请求报文接受、响应报文返回、请求编码等定义的内容；
业务逻辑层：主要做业务逻辑处理，这一层包括数据映射DTO转VO，业务核心逻辑编写，组合不同数据仓库，做业务逻辑；
数据访问层：主要做数据存储，包括数据映射VO转PO，数据接口的定义，映射XML的编写。
DDD分层架构
DDD分层架构也可以叫四层架构，主要由用户接口层、应用层、领域层、基础层；
用户接口层：负责向用户显示信息和解释用户指令，比如用户、程序、自动化脚本、批处理脚本等；
应用层：主要用于协调多个聚合的服务和领域对象完成服务编排和组合，可以调本地也可以调远程的服务、包括权限验证、事务控制、防重幂等，不要把核心的业务逻辑放到这里；
领域层：实现核心逻辑，包括聚合根、实体、值对象、领域服务，包括业务扩展点、校验规则、组合聚合服务等相关功能；
基础层：提供通用的技术和基础服务，包括一些第三方工具类、缓存、数据库、文件等，采用依赖倒置的设计，于其他层解耦。
演变
三层架构向DDD架构演变，主要发生在逻辑层和数据库访问层
- 新增DTO，给前端数据可用性更高，更灵活；
- 三层架构的业务逻辑层改为应用层和领域层，使得业务逻辑不混乱，应用快速响应前端的变化；
- 基础层和数据访问层的设计变化，通过依赖倒置实现基础设置对基础资源的解耦，应对主流技术的变化。
项目结构
用户接口层
Assembler：DTO与实体对象相互转换和数据交换，与DTO同时出现；
Dto：数据传输载体，DTO可以将领域对象与外界隔离；
Facade：粗接口粒度定义，将请求给多个应用服务处理；
应用层
event: 主要存放事件相关代码，包括两个子目录publish和subscribe，放发布订阅相关代码，这里可以领不同领域服务订阅也可以是微服务之间的订阅；
service:应用服务，主要对外部的服务进行封装、编排和封装，提供粗粒度的服务，也是一段独立的业务逻辑
领域层
Aggregate：聚合软件包的根目录，根据聚合的名称命名，里面可以定义实体、聚合根、实体、值对象以及领域服务，可以独立拆分成微服务；
Entity：存放聚合根、实体、值对象、工厂模式相关 代码，统一实体的相关逻辑，都放在该类中，采用充血模式；
Event：存放事件实体以及事件活动相关的逻辑代码；
Service：领域服务，根据不同的实体组合的业务逻辑；
Repository：存放聚合查询和持久化领域对象的代码；
基础层
Config：主要存放配置相关代码，比如springboot自动配置内和集成第三方组件的配置；
Util：主要存放平台、开发框架、消息、数据库、缓存、文件、总线、网关、第三方类库、通用算法等基础代码，你可以为不同的资源类别建立不同的子目录;
示例代码
https://github.com/itrickzhang/ddd-demo1
本文由博客一文多发平台 OpenWrite 发布！
