Golang领域模型-依赖倒置

前言：为什么要用整篇文章来写好像跟领域模型干系不大的《依赖倒置》呢？因为《依赖倒置》是六边形架构的核心！毫不夸张的说，不理解《依赖倒置》的程序员只能写功能，没法写出框架来！不论是依赖注入di或者依赖倒置dip，全部都是根据当前成员变量的类型，框架自动注入实例的。区别在于成员变量是指针接收还是接口接收。具体如何自动注入，请看<<六边形架构>>和<<资源库>>章节。

一、如果不进行依赖倒置会怎样？

我们先看看什么是依赖倒置，教科书式的解释就是：

高层模块不应依赖于低层模块，二者应依赖于抽象。

抽象不应依赖于细节，细节应依赖于抽象。

我们商品领域服务需要使用Repository来持久化数据，中二代码写成这样：

代码示例

资源库具体实现基础设施（DB）的功能

外部资源的实现
领域模型依赖资源库

直接依赖repository
领域模型直接使用以来的资源库实现

使用repository的实现

这样做的缺点是什么？

难以维护
内部（领域模型）通常是业务逻辑和策略，这里就是DDD里面的领域模型，一个软件区别于其他软件的核心就在于业务逻辑和策略实现（也就是领域模型），而外部更多的是外部资源等基础设施。PS：内部外部概念可参考前文---《Golang领域模型-六边形架构》

如果领域模型依赖基础设施，那就是业务逻辑依赖技术细节，技术细节的改变将会对业务逻辑产生影响，使其不得不改变。这样是不合理的。

复用困难
越核心的领域模型，复用价值越高，如果对基础设施进行依赖，那么复用将会变得很困难。

二、如何进行依赖倒置？

计算机科学中的所有问题都可以通过引入一个间接层得到解决。
All problems in computer science can be solved by another level of indirection
—— David Wheeler

实现：domain中引入dependency包定义抽象层

dependency抽象层

代码示例：

定义了商品仓储实现所需要满足的接口。

抽象层
商品领域服务成员变量直接引用抽象接口，框架负责依赖注入

领域模型依赖抽象

商品领域模型中使用抽象出来的GoodsRepo方法

领域模型依赖抽象

外部资源具体实现抽象接口

外部资源具体实现抽象接口

注意： var _ dependency.GoodsRepo = new(Goods) 我们用来检查是否实现了接口

三、六边形架构核心-依赖倒置

前面讲完基础，现在开始上大戏了！

为什么说六边形架构的核心是依赖倒置？

因为六边形架构不分高低层，而分内外部，严格的将基础设施和领域模型分割开来。领域模型实现很简单，但是将领域模型与DB，Redis，MQ等基础设施连接起来却很困难。

如何连接？依赖倒置！

main函数中安装基础设施kafka

安装kafka

实体中抽象领域事件接口

抽象领域事件接口

kafka实现领域事件接口

实现领域事件接口

订单实体发送领域事件

发送领域事件

依赖倒置的变与不变

通过第一、二小结概念的理解，观察第三小结的代码。

Kafka是个优秀的消息队列中间件，它虽然很好，但只是基础设施，不是系统的核心部分，也许不久的某一天我们就会把它替换掉。亦或是替换掉别的中间件~

如果没有依赖倒置怎么办？
修改业务代码？将所有用到过kafka的地方全部重新写一遍？下次有变化继续写？程序员听了想打人！

有了依赖倒置怎么办？

新的中间件只需要实现领域事件接口。
在main中重新安装。

这就是依赖倒置的魅力，没有什么是不变的，重要的是将领域模型与基础设施解耦开来。这样替换只需要重写领域事件，让领域模型保持相对稳定，不会随着基础设施的变化而被动变化。

四、品一品

细品以上两种代码，第二种实现方式中，领域模型没有像原来一样直接依赖外部资源，而是将依赖关系“倒置”过来，让基础设施去依赖由领域模型定义好的接口。

回前言所问，为什么要用一篇文章来解释依赖倒置，这就是六边形的核心，外部依赖内部，内部倒置基础设施---freedom！

总结一下：

常用的实现方式是基础设施有自己的接口，领域模型依赖基础设施提供的接口，比如基础设施有自己的接口，领域模型依赖基础设施的接口，这样直接依赖的实现方式。

但是按照依赖倒置的原则，接口的所有权是被倒置的，表现在于接口是被领域模型的，领域模型拥有接口的所有权，基础设施实现接口。这样基础设施的改动不会影响领域模型，领域模型的复用不会依赖基础设施。

1.依赖于构建出来的抽象，而不是具体类。
2.依赖倒置的关键是接口所有权的倒置。