在我的博客阅读本文

1. DDD的实现架构

DDD的实现架构有很多种，这些架构都是一种关注点分离模式的实现，也是SOLID单一职责原则的体现，将人们关注的一个职责与其他职责分离，不要试图混合在一起。传统的SOA架构在这方面有很大缺陷，造成了一种单体耦合的架构，虽然这样的大型服务能够实现一定程度的复用和重用，但是在重用和解耦之间需要有一个取舍，在这两者之间如果非选择一个，那么首先选择解耦。通过解耦可以实现更小粒度的重用，虽然这种重用粒度太细小会使得提高生产效率方面的效果不是很明显，但是随着系统的扩展和复杂性的提高，其优点将逐步体现。

1.1. 三层架构

常见的三层架构：表现层、应用层和数据层

• 表现层

表现层是与外界进行联系，处理所有传入请求和放回响应的地方，这是MVC模式实现的地方。表现层依赖应用层来执行系统提供的所有功能。表现层仅仅依赖应用层，在React.JS或Vue.JS等浏览器富客户端流行的情况下，表现层已经在浏览器客户端实现，而传统SpringMVC则是在后端服务器实现MVC。

• 应用层

应用层是开发应用程序提供所有功能的地方，这也是业务逻辑所在，业务领域核心所在，也就是进行所有业务规则验证的地方。应用层仅仅依赖数据层，保存所有的数据供以后使用，或获取某些先前保存的数据，应用层将其计算结果返回表现层。

• 数据层

数据层，保存所有的数据供以后使用。

在这种分层下，应用层既负责业务决策，也负责业务协调，在复杂在业务变得复杂后，应用层会越来越臃肿。

优点

• 层是隔离的，每一层可以独立修改。
• 关注点分离，每个层处理应用程序一个方面。
• 开发人员熟悉这种简单架构。

缺点

• 对于简单CURD来说，也需要走整个3层
• 应用层依赖数据层，所有的业务逻辑都会依赖到数据层的数据库，数据库负载大，而且如果数据库技术进行变更，应用层也需要进行改造。
• 读写都在一起无法分离读写关注点，无法单独针对查询进行独立优化。

1.2. 传统DDD分层架构

传统DDD架构在传统三层架构基础上增加一个领域层，将数据库层或仓储层作为基础设施层，而应用层则用来协调领域层和基础设施层，因为最终一个功能是需要业务领域决策加上仓储来实现的：

• 表现层传入失血模型DTO对象传输数据
• 应用层委派领域层执行业务决策（可能需要DTO→领域模型类）
• 应用层委派基础设置层（仓储）进行数据保存

1.3. 清洁（Clean）架构

清洁（Clean）架构是著名软件工程大师RobertC.Martin提出的一种架构整洁清晰之道，也是当前各种语言开发的目标架构。

同心圆代表各种不同领域的软件。一般来说，越深入代表软件层次越高。外圆是战术实现机制，内圆是战略核心策略。

此架构能够工作的关键是依赖规则。这条规则规定源代码只能向内依赖，在最里面的部分对外面一点都不知道，也就是内部不依赖外部，而外部则依赖内部。这种依赖包含代码名称、类的函数、变量或任何其他命名软件实体。

同样，在外圆中使用的数据格式不应被内圆中使用，特别是如果这些数据格式由外面一圈的框架生成时。清洁架构不希望任何外圆的东西影响内圆的业务核心