问题:我应该将依赖关系反转,让
我可以想象系统使用任何一种架构都可以工作,那么这只是竞争设计问题的经典案例,还是我完全错过了什么?
编辑:这个高票答案似乎表明领域模型应该被隔离,每个对象只向系统的其余部分公开一个接口。
DomainModel
依赖于持有系统接口和高级策略的Core
吗?
我们是否会将丰富的领域模型视为实现细节?
背景:所以我的DomainModel
在一个独立的项目中,没有向外部的依赖。我的所有子系统服务都在单独的项目中,它们互相不知道。我还有一个Core
项目,其中包含所有特定于系统的内容,如接口、枚举、验证类、扩展和其他所有服务都不被归类为低级别实现细节的东西。Core
除了对DomainModel
的依赖之外没有向外部的依赖,所有的服务都依赖于Core
,并且也依赖于DomainModel
。
我的当前想法:我听说过设计语句,比如:
“领域模型不应该有向外部的依赖”
和潜在地相对的是
“高级策略不应依赖于低级别实现细节”
和
“模块之间的依赖方向应该是稳定性的方向”
我发现在开发系统时,域模型的实现经常会有很大的变化,所有业务规则和对象都存在,但我不认为大多数域模型都是稳定的,可能只有一些像 ValueObject
这样的模型是稳定的。
我认为将 DomainModel
依赖于 Core
的好处在于高级策略不需要了解域模型的实现细节,同时域模型也与系统的其余部分隔离开来。事实上,每个其他项目都将仅依赖于 Core
,并且仍然不知道彼此。当我更改 DomainModel
(我经常这样做)时,构建将重新编译该项目,而不是像目前这样重新编译整个解决方案。
Core
中的一个特殊文件夹中。对于这些接口,我还想删除“ I”前缀,并使用MoneyType:Money
[interface]。我想我唯一能实例化领域对象的方式是通过抽象工厂,所以我还需要更多的抽象工厂。现在,我确实喜欢能够在系统的“任何地方”实例化具体的领域对象,几乎像BCL的扩展或抽象(这也是域模型的一部分吧?)。我可以想象系统使用任何一种架构都可以工作,那么这只是竞争设计问题的经典案例,还是我完全错过了什么?
编辑:这个高票答案似乎表明领域模型应该被隔离,每个对象只向系统的其余部分公开一个接口。
https://dev59.com/FnRA5IYBdhLWcg3wzhRY#821300
目前来看,这对我来说感觉更好,因为系统的其余部分没有无限制地访问域对象(因此每次更改都需要重新编译它们)。然而,将这种依赖关系完全反转以实现完全隔离并不是一项微不足道的任务,因此我非常乐意进行更多的讨论和回答。
更多编辑:因此,我尝试了重构,在我开始尝试实现自己的简单DI容器时,我决定事情开始变得有点臭味相投和有些荒谬。
完全隔离DomainModel
的任何感知优势都被指数级增加的复杂性和代码行数所抵消(至少对我来说是这样)。因此,我将架构重构为DomainModel
仅依赖于Core
,后者现在仅包含我使用的按设计约定的类、自定义集合、注释和常见扩展。我将所有特定于系统的接口和基础设施移到一个新项目Infrastructure
中,所有子系统服务都依赖于此(这里没有特定的技术,因此可能不是典型的基础设施层?)。