领域驱动设计之体系架构模式

我们传统的体系架构模式是三层架构：



我认为传统的三层架构主要存在以下问题：

1.业务层直接访问数据访问层，也就是业务层直接与数据打交道，与数据实现机制绑定太紧。

2.数据访问层的地位太突出，而且没有体现系统所需要的其他基础服务机制。

3.业务层并没有很好的指导应该如何进行构建。

DDD经典分层架构：



一.用户界面层

1.请求应用层获取用户需要显示的信息

2.发送命令给应用层要求执行某个命令

二.应用层

对用户界面层提供各种应用功能（包括信息获取与命令执行），应用层不包含业务逻辑，业务逻辑是由应用层调用领域层（领域对象或领域服务）来完成，应用层是跟薄的一层。

三.领域层

包含领域对象与领域服务，完成系统所需的业务处理，是系统的的核心。业务逻辑与仓储接口都在领域层。

四.基础结构层

包含其他层所需要使用的所有基础服务于技术，比如仓储的实现(与数据库打交道)、短消息发送、Json字符串处理等。

注意：

聚合根负责聚合的业务规则一致性，如果需要保证聚合间设计到的数据库方面的事务的一致性，通常通过工作单元机制处理，工作单元可以在领域服务中使用，也可以在应用层服务中使用，仓储实现是不用考虑数据库的事务的。