- 领域驱动设计(Thoughtworks洞见)
- ThoughtWorks中国
- 345字
- 2020-06-25 10:30:57
依赖关系
代码目录结构并不能表达分层体系中各层的依赖关系,比如Domain层是不应该依赖于其它任何一层的。维护各层的依赖关系是至关重要的,很多团队在实施的过程中都没有能够建立起这样的工程纪律,最后造成代码结构的混乱,领域模型也被打破。
根据分层架构的规则,我们可以看到示例中的代码结构如下图。

Domain是不依赖于任何的其它对象的。Repositories是依赖于Domain的,实现如下:引用了model.h。

Services是依赖于Domain和Repositories的,实现如下:引用了model.h和repository.h


为了维护合理的依赖关系,依赖注入(Depedency Injection)是需要经常采用的实现模式,它作为解耦合的一种方法相信大家都不会陌生,具体定义参见这里。
在测试构建时,我们利用了一个IoC框架(依赖注入的实现)来构造了一个Api,并且把相关的依赖(如CargoService)注入给了这个Api。这样既没有破坏Interface和Service的单向依赖关系,又解决了测试过程中Api的实例化要求。