我们传统的体系架构模式是三层架构：
我认为传统的三层架构主要存在以下问题：
1.业务层直接访问数据访问层，也就是业务层直接与数据打交道，与数据实现机制绑定太紧。
2.数据访问层的地位太突出，而且没有体现系统所需要的其他基础服务机制。
3.业务层并没有很好的指导应该如何进行构建。
DDD经典分层架构：
一.用户界面层
1.请求应用层获取用户需要显示的信息
2.发送命令给应用层要求执行某个命令
二.应用层
对用户界面层提供各种应用功能（包括信息获取与命令执行），应用层不包含业务逻辑，业务逻辑是由应用层调用领域层（领域对象或领域服务）来完成，应用层是跟薄的一层。
三.领域层
包含领域对象与领域服务，完成系统所需的业务处理，是系统的的核心。业务逻辑与仓储接口都在领域层。
四.基础结构层
包含其他层所需要使用的所有基础服务于技术，比如仓储的实现(与数据库打交道)、短消息发送、Json字符串处理等。
注意：
聚合根负责聚合的业务规则一致性，如果需要保证聚合间设计到的数据库方面的事务的一致性，通常通过工作单元机制处理，工作单元可以在领域服务中使用，也可以在应用层服务中使用，仓储实现是不用考虑数据库的事务的。
欢迎加入QQ讨论群：309287205