Golang领域模型

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

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

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

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

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

代码示例

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

外部资源的实现

2. 领域模型依赖资源库

直接依赖repository

3. 领域模型直接使用以来的资源库实现

使用repository的实现

这样做的缺点是什么？

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

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

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

二、如何进行依赖倒置？

计算机科学中的所有问题都可以通过引入一个间接层得到解决。 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等基础设施连接起来却很困难。

如何连接？依赖倒置！

main函数中安装基础设施kafka

安装kafka

2. 实体中抽象领域事件接口

抽象领域事件接口

3. kafka实现领域事件接口

实现领域事件接口

4. 订单实体发送领域事件

发送领域事件

依赖倒置的变与不变

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

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

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

有了依赖倒置怎么办？ 1. 新的中间件只需要实现领域事件接口。 2. 在main中重新安装。

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

四、品一品

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

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

总结一下：

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

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

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