前言:为什么要用整篇文章来写好像跟领域模型干系不大的《依赖倒置》呢?因为《依赖倒置》是六边形架构的核心!毫不夸张的说,不理解《依赖倒置》的程序员只能写功能,没法写出框架来!不论是依赖注入di或者依赖倒置dip,全部都是根据当前成员变量的类型,框架自动注入实例的。区别在于成员变量是指针接收还是接口接收。具体如何自动注入,请看《六边形架构》和《资源库》章节。
我们先看看什么是依赖倒置,教科书式的解释就是:
高层模块不应依赖于低层模块,二者应依赖于抽象。 抽象不应依赖于细节,细节应依赖于抽象。
我们商品领域服务需要使用Repository来持久化数据,中二代码写成这样:
代码示例
1. 资源库具体实现基础设施(DB)的功能
外部资源的实现
2. 领域模型依赖资源库
直接依赖repository
3. 领域模型直接使用以来的资源库实现
使用repository的实现
这样做的缺点是什么?
如果领域模型依赖基础设施,那就是业务逻辑依赖技术细节,技术细节的改变将会对业务逻辑产生影响,使其不得不改变。这样是不合理的。
计算机科学中的所有问题都可以通过引入一个间接层得到解决。 All problems in computer science can be solved by another level of indirection—— David Wheeler
实现:domain中引入dependency包定义抽象层
dependency抽象层
代码示例:
1. 定义了商品仓储实现所需要满足的接口。
抽象层
2.商品领域服务成员变量直接引用抽象接口,框架负责依赖注入
领域模型依赖抽象
3.商品领域模型中使用抽象出来的GoodsRepo方法
领域模型依赖抽象
4. 外部资源具体实现抽象接口
外部资源具体实现抽象接口
注意: var _ dependency.GoodsRepo = new(Goods) 我们用来检查是否实现了接口
前面讲完基础,现在开始上大戏了!
因为六边形架构不分高低层,而分内外部,严格的将基础设施和领域模型分割开来。领域模型实现很简单,但是将领域模型与DB,Redis,MQ等基础设施连接起来却很困难。
如何连接?依赖倒置!
安装kafka
2. 实体中抽象领域事件接口
抽象领域事件接口
3. kafka实现领域事件接口
实现领域事件接口
4. 订单实体发送领域事件
发送领域事件
通过第一、二小结概念的理解,观察第三小结的代码。
Kafka是个优秀的消息队列中间件,它虽然很好,但只是基础设施,不是系统的核心部分,也许不久的某一天我们就会把它替换掉。亦或是替换掉别的中间件~
如果没有依赖倒置怎么办? 修改业务代码?将所有用到过kafka的地方全部重新写一遍?下次有变化继续写?程序员听了想打人!
有了依赖倒置怎么办? 1. 新的中间件只需要实现领域事件接口。 2. 在main中重新安装。
这就是依赖倒置的魅力,没有什么是不变的,重要的是将领域模型与基础设施解耦开来。这样替换只需要重写领域事件,让领域模型保持相对稳定,不会随着基础设施的变化而被动变化。
细品以上两种代码,第二种实现方式中,领域模型没有像原来一样直接依赖外部资源,而是将依赖关系“倒置”过来,让基础设施去依赖由领域模型定义好的接口。
回前言所问,为什么要用一篇文章来解释依赖倒置,这就是六边形的核心,外部依赖内部,内部倒置基础设施---freedom!
总结一下:
常用的实现方式是基础设施有自己的接口,领域模型依赖基础设施提供的接口,比如基础设施有自己的接口,领域模型依赖基础设施的接口,这样直接依赖的实现方式。
但是按照依赖倒置的原则,接口的所有权是被倒置的,表现在于接口是被领域模型的,领域模型拥有接口的所有权,基础设施实现接口。这样基础设施的改动不会影响领域模型,领域模型的复用不会依赖基础设施。
1.依赖于构建出来的抽象,而不是具体类。 2.依赖倒置的关键是接口所有权的倒置。
领取专属 10元无门槛券
私享最新 技术干货