共计 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.依赖倒置的关键是接口所有权的倒置。**
