前言：为什么要用整篇文章来写好像跟领域模型干系不大的《依赖倒置》呢？因为《依赖倒置》是六边形架构的核心！毫不夸张的说，不理解《依赖倒置》的程序员只能写功能，没法写出框架来！不论是依赖注入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包定义抽象层
代码示例：
-
定义了商品仓储实现所需要满足的接口。
抽象层 商品领域服务成员变量直接引用抽象接口，框架负责依赖注入
- 商品领域模型中使用抽象出来的
GoodsRepo方法
-
外部资源具体实现抽象接口
外部资源具体实现抽象接口
注意： var _ dependency.GoodsRepo = new(Goods) 我们用来检查是否实现了接口
三、六边形架构核心-依赖倒置
前面讲完基础，现在开始上大戏了！
为什么说六边形架构的核心是依赖倒置？
因为六边形架构不分高低层，而分内外部，严格的将基础设施和领域模型分割开来。领域模型实现很简单，但是将领域模型与DB，Redis，MQ等基础设施连接起来却很困难。
如何连接？依赖倒置！
- main函数中安装基础设施kafka
- 实体中抽象领域事件接口
- kafka实现领域事件接口
- 订单实体发送领域事件
依赖倒置的变与不变
通过第一、二小结概念的理解，观察第三小结的代码。
Kafka是个优秀的消息队列中间件，它虽然很好，但只是基础设施，不是系统的核心部分，也许不久的某一天我们就会把它替换掉。亦或是替换掉别的中间件~
如果没有依赖倒置怎么办？
修改业务代码？将所有用到过kafka的地方全部重新写一遍？下次有变化继续写？程序员听了想打人！
有了依赖倒置怎么办？
- 新的中间件只需要实现领域事件接口。
- 在main中重新安装。
这就是依赖倒置的魅力，没有什么是不变的，重要的是将领域模型与基础设施解耦开来。这样替换只需要重写领域事件，让领域模型保持相对稳定，不会随着基础设施的变化而被动变化。
四、品一品
细品以上两种代码，第二种实现方式中，领域模型没有像原来一样直接依赖外部资源，而是将依赖关系“倒置”过来，让基础设施去依赖由领域模型定义好的接口。
回前言所问，为什么要用一篇文章来解释依赖倒置，这就是六边形的核心，外部依赖内部，内部倒置基础设施---freedom！
总结一下：
常用的实现方式是基础设施有自己的接口，领域模型依赖基础设施提供的接口，比如基础设施有自己的接口，领域模型依赖基础设施的接口，这样直接依赖的实现方式。
但是按照依赖倒置的原则，接口的所有权是被倒置的，表现在于接口是被领域模型的，领域模型拥有接口的所有权，基础设施实现接口。这样基础设施的改动不会影响领域模型，领域模型的复用不会依赖基础设施。
1.依赖于构建出来的抽象，而不是具体类。
2.依赖倒置的关键是接口所有权的倒置。
目录
- golang领域模型-开篇
- golang领域模型-六边形架构
- golang领域模型-实体
- golang领域模型-资源库
- golang领域模型-依赖倒置
- golang领域模型-聚合根
- golang领域模型-CQRS
- golang领域模型-领域事件
项目代码 https://github.com/8treenet/freedom/tree/master/example/fshop
PS：关注公众号《从菜鸟到大佬》，发送消息“加群”或“领域模型”，加入DDD交流群，一起切磋DDD与代码的艺术！
