出现背景
三层应用架构：数据 - 应用 (业务逻辑层)- 展现，通常是以数据位为起点进行数据库分析设计,服务层过重，数据模型失血，没东西 面条式编程或者面向数
出现背景
三层应用架构：数据 - 应用 (业务逻辑层)- 展现，通常是以数据位为起点进行数据库分析设计,服务层过重，数据模型失血，没东西.
面条式编程或者面向数据库编程，服务层围绕数据库作业完成业务逻辑，经常一条线撸到底；
代码一整块一整块的过重，很难扩展复用；
数据库模型只是数据库映射，没有相关的行为支撑，行为都被上一层 Service 给完成等了，因此是失血的领域模型；
领域模型是对业务模型的抽象，DDD革命性在于：
领域模型准确反映了业务语言，传统数据对象除了简单setter/getter方法外，没有任何业务方法，即失血模型
而DDD领域采用充血模型（业务方法定义在实体对象中，例如：生成订单时，判断商品不能为空）
分层
- 接口层
- 对外提供能力/接口，HTTP接口，RPC接口等
- 应用层
- 接口与核心之间的层次，主要是将核心对象封装、组合成完整的业务流程，为接口提供服务
- 领域层/核心层
- 将核心业务逻辑拆分为功能相对独立的各个子模块。 子模块和具体业务流程无关或关联性不大，封装了核心的知识，并对外提供抽象接口。
- 基础设施层/防腐层/ACL
- 服务对外依赖，包括数据库、消息队列等
三层架构到四层架构之间的演进
-
三层架构向DDD分层架构演进，主要发生在业务逻辑层和数据访问层。
-
DDD分层架构在用户接口层引入了DTO，给前端提供了更多的可使用数据和更高的展示灵活性。
-
DDD分层架构对三层架构的业务逻辑层进行了更清晰的划分，改善了三层架构核心业务逻辑混乱，代码改动相互影响大的情况。
-
DDD分层架构将业务逻辑层的服务拆分到了应用层和领域层。应用层快速响应前端的变化，领域层实现领域模型的能力。
-
-
另一个重要的变化发生在数据访问层和基础层之间。
三层架构数据访问采用DAO方式；
DDD分层架构的数据库等基础资源访问，采用了仓储（Repository）设计模式，通过依赖倒置实现各层对基础资源的解耦。
仓储又分为两部分：仓储接口和仓储实现。
仓储接口放在领域层中，仓储实现放在基础层。原来三层架构通用的第三方工具包、驱动、Common、Utility、Config等通用的公共的资源类统一放到了基础层。
传统三层架构向DDD分层架构的演进，体现的正是领域驱动设计思想的演进。
