参考引用

1.如何落地业务建模（徐昊）

在使用领域驱动设计时，我们通常会将系统分成四层：

1. 展现层（Representation Layer）：负责用户信息的展示以及交互。
2. 应用层（Application Layer）：负责支撑具体的业务或者交互流程，将业务逻辑组织为软件功能。
3. 领域层（Domain Layer）：核心的领域概念、信息与规则。它在整个系统中应该处于最稳定的模块，他不会随着应用层的流程、展现层的界面以及基础设施层的能力改遍而变化。
4. 基础设施层（Infrastructure Layer）：通用的技术能力，比如数据库、消息总线等等。

为什么要分层？

每一层变化的原因和频率都不一样，下层的变化会影响上层，所以为了隔离变化，我们希望通过层来控制变化的传播。因此下层组件应该比上层组件更加稳定。

基础设施层和领域层谁稳定

在软件系统有限的生命周期内，我们可以认为领域层应该是不变的。领域层应该是最稳定的。

如图，领域模型对基础设施的态度是非常微妙的：

• 领域逻辑必须依赖基础设施才能完成相应的功能；
• 领域模型必须强调自己稳定性，才能维持它在架构中的核心位置。

而作为被人为认定为的绝对稳定，它不能依赖任何非领域逻辑（除了基础库）。任何对其他逻辑的依赖都会带来修改的传递，会使领域层变得不稳定。由于依赖了基础层，所以领域层在层级中则不是一个最稳定的层，基础设施层才是。

如何解决领域层和基础设施层的依赖关系

基础设施不是层

因为我们人为地规定了领域层最稳定，那么用以实现领域层的基础设施层，就不能比领域层更稳定。因此我们的选择只有两个：要么承认领域层并不是最稳定的（也就是领域层是“在特定技术栈上的领域模型实现”）；要么就别把基础设施当作层来看。

说句题外话，其实我始终推荐不要过分强调领域层的绝对独立性，心里坦然接受领域层并不是无约束的理想化实现，而是受特定技术栈与技术生态环境约束的实现，就没那么多烦恼与纠结了。

能力供应商模式

通过能力与能力供应商，层与层之间出现了另一种交互的可能：上一层作为下一层的能力供应商，参与到下一层的业务与流程中去。而这种参与，并不会带来额外的依赖。示意图如下：

接口隔离原则、倒置依赖原则：

1. 将具有业务含义的能力抽象成接口纳入领域层。
2. 基础设施层来实现领域层的业务接口。
3. 借助DI框架，实现依赖倒置、接口隔离。这样领域层只依赖于本层的接口，基础设施层。

通过从技术组件抽象具有业务含义的能力，我们就能将基础设施转变为具有这种能力的供应商。于是，我们就能帮助领域层实现了它希望的那种“不正当关系”，既使用了基础设施，又对它没有依赖：我们依赖的是领域层内的能力接口（SOLID 中的接口隔离原则），而不是基础设计的实现（SOLID 中的倒置依赖原则）。