领域驱动设计-架构分层(接口隔离、依赖倒置原则的应用)

参考引用

1.如何落地业务建模(徐昊)

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

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

为什么要分层?

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

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

在软件系统有限的生命周期内,我们可以认为领域层应该是不变的。领域层应该是最稳定的。
image.png
如图,领域模型对基础设施的态度是非常微妙的

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

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

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

基础设施不是层

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

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

能力供应商模式

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

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

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

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

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享