领域驱动设计：分层架构

分层架构是运用最为广泛的架构模式， 几乎每个软件系统都需要通过层来隔离不同的关注点，以此应对不同的需要变化，使得这种变化可以独立进行，此外，分层架构模式还可以用于隔离业务复杂度和技术复杂度。

Robert Martin认为单一职责原则就是”一个类应该只有一个引起它变化的原因”，换句话，就是如果有两个引起类变化的原因，就需要分离。单一职责原则可以理解为架构原则， 这里我们考虑的不是类，而且层次，这就是为什么我们需要将业务和基础设施进行分开的原因。

分层架构演进

分层架构-图1.png

左边为传统的经典三层架构，在此基础上，领域驱动里面提出了四层架构，由原来的业务层分为应用层和领域层。

• “新增的应用层”主要负责：协调对领域对象的操作，分配工作，与其它系统的应用层进行交互的必要渠道, 本身不包括业务逻辑, 是非常薄的一层， 与业务用例一一对应
• 领域层： 负责表达业务概念，业务状态信息以及业务规则。
• 基础设施层： 向其他层提供通用的技术能力， 为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件等。

分层依赖关系

分层架构图2.png

一般的分层架构都是，上层依赖下层，从上自下的依赖关系， 但是DDD中，我们推荐应该依赖抽象，而不是具体的实现，所以领域层不会直接依赖基础设施层，而是依赖与接口，比如这里的资源库就是接口，然后基础设施层，也依赖于资源库，并通过依赖注入或者控制反转的方式，提供具体的底层实现； 这样很好的做的了技术复杂度和业务复杂度的隔离。即使底层技术实现细节的变更，也不会影响到领域层。

A. 高层次的模块不应该依赖于低层次的模块，它们都应该依赖于抽象。
B. 抽象不应该依赖于具体实现细节，具体实现细节应该依赖于抽象。
- Robert C. Martin

根据面向对象设计里面的依赖倒置原则，我们可以把它用于架构设计的参考原则，其实就是面向接口的设计原则，就像构建房屋一样，我们需要稳定的地基，那么在编程的世界，抽象和接口是相对稳定的，所以我们的分层架构，可以不像传统的三层架构那样，从上到下的进行依赖。

分层架构类比

image.png

洋葱架构，六边形架构，整洁架构，都是分层架构，他们只是更好的表达出了，领域逻辑处于系统架构核心的位置。

比如，出名的六边形架构，它通过内外两个六边形，进行技术复杂度和业务复杂度的隔离，这里的分层，只是名字不同，和我们上面提高的分层架构能一一对应上，比如领域模型对应领域层，应用程序对应应用层，端口和适配器对应基础设施层。

同理，整洁架构里面的enties对应领域层，Use cases对应应用层，controllers，gateways和presenters对应我们的基础设施层。

总体来说，他们更好的表达了领域逻辑的核心地位。

分层架构代码模型

代码模型属于软件架构的一部分，通过它展现了模块的划分，我们的分层更多的是逻辑上的水平分层，体现在代码上面，主要是通过包或者模块。

image

各个层的职责和关系如下：

1. Domain层内要有Repository负责存取对象、Factory负责创建对象、Domain service负责做领域层大的业务
2. Repository接口要在Domain层
3. Repository的实现要在Domain层外
4. 实现依赖Domain层，Domain层不依赖实现
5. Application层（包括resource目录和facade目录）在Domain层外，不能有业务逻辑，只负责调度不同聚合的Domain service。Application service 可以依赖domain层的一切对象，但是domain层一切对象都不依赖外部对象
6. 不同聚合的Domain不在一个包里，彼此的访问通过Application service转发