共计 1060 个字符,预计需要花费 3 分钟才能阅读完成。
前言
依赖倒置跟领域驱动设计其实关系不大,但它是六边形架构的核心。如果你无法理解依赖倒置,那你就写不出任何一个框架。
Robert Martin(罗伯特. 马丁)在《架构简洁之道》这本书里总结了五大设计原则(也叫SOLID原则),依赖倒置是其中的一种设计原则。
- Single Responsibility Principle(单一职责原则)
- Open Closed Principle(开闭原则)
- Liskov Substitution Principle(里氏替换原则)
- Interface Segregation Principle(接口隔离原则)
- Dependency Inversion Priciple(依赖倒置原则)
一、依赖倒置原则
-
高层模块不依赖于低层模块,两者都应该依赖于抽象
-
抽象不应该依赖于细节,细节应该依赖于抽象
二、不使用依赖倒置会有什么问题?
代码示例
-
资源库实现细节
-
领域模型依赖资源库的实现
-
领域模型直接使用资源库的实现
上述代码的问题是什么?
1.难以维护
在六边形架构里内部是业务的核心逻辑和策略,也就是DDD里的领域模型。一个软件区别于其他软件的核心就在于业务逻辑和策略实现,而外部仅仅只是提供内部需要用的的资源等。
如果领域模型依赖外部资源库,那就是业务逻辑依赖于技术细节,在依赖倒置的定义里就是上层模块依赖于底层模块,抽象依赖于细节。这样导致的问题就是技术细节的改变将会对业务逻辑产生影响,使其不得不做改变。
2.难以复用
越核心的领域模型,复用的价值越高,这也是抽象内部模型的价值所在。如果对外部进行了依赖,那么复用将会变得很困难。
三、如何进行依赖倒置
-
在
domain
中引入dependency
包,定义抽象层 -
定义用户存储实现所需要的接口协议
-
用户领域服务使用成员变量引用抽象接口,DT-Go框架负责引入注入
-
领域服务使用抽象接口
-
资源库负责抽象接口的具体实现
四、依赖倒置的变与不变
观察第三节里的代码,用户领域服务并不关心需要的数据从哪里来,它只需要定义好抽象接口协议即可。而外部资源库负责做具体的底层实现,其实就是对内部屏蔽了实现细节。至于未来如果用户的数据从Mysql
迁移到MongoDB
,只需要在资源库里做改变,让领域模型保持相对稳定,不会随着基础设施的变化而被动变化。
按照依赖倒置的原则,接口的所有权是被倒置的,表现在于接口是领域模型的,领域模型拥有接口的所有权,外部资源库/基础设施负责实现接口。这样外部的改动不会影响领域模型,领域模型的复用不会依赖外部实现。
1.依赖于构建出来的抽象,而不是具体类。
2.依赖倒置的关键是接口所有权的倒置。**