Golang 领域模型 - 依赖倒置

用户头像
奔奔奔跑
关注
发布于: 2020 年 09 月 18 日
Golang领域模型-依赖倒置

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



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



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



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

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



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



代码示例



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



外部资源的实现



2. 领域模型依赖资源库



直接依赖repository



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



使用repository的实现



这样做的缺点是什么?



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



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



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



二、如何进行依赖倒置?



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



如何连接?依赖倒置!



  1. main函数中安装基础设施kafka

安装kafka



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

抽象领域事件接口



3. kafka实现领域事件接口

实现领域事件接口



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

发送领域事件



依赖倒置的变与不变



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



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



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



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



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



四、品一品



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



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



总结一下:



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



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



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



目录



  • golang领域模型-开篇

  • golang领域模型-六边形架构

  • golang领域模型-实体

  • golang领域模型-资源库

  • golang领域模型-依赖倒置

  • golang领域模型-聚合根

  • golang领域模型-CQRS

  • golang领域模型-领域事件



项目代码 https://github.com/8treenet/freedom/tree/master/example/fshop



PS:加我微信:stargaze111,拉你加入DDD交流群,一起切磋DDD与代码的艺术!



发布于: 2020 年 09 月 18 日 阅读数: 783
用户头像

奔奔奔跑

关注

还未添加个人签名 2018.08.16 加入

还未添加个人简介

评论 (3 条评论)

发布
用户头像
控制反转,依赖注入这个概念在Java里很基本,在go这边需要大量的手动处理,虽然也有一些开源框架,比如dip,但比Java的难用多了。
2020 年 09 月 18 日 18:01
回复
dig,打错了。
2020 年 09 月 18 日 18:04
回复
蛋疼了,没有办法呢,语言特性决定的
2020 年 09 月 19 日 10:45
回复
没有更多了
Golang领域模型-依赖倒置