域模型对视图模型的依赖有多糟糕？答案

【问题标题】：How bad is it for Domain Models to have a dependency on View Models?域模型对视图模型的依赖有多糟糕？
【发布时间】：2019-09-04 08:28:05
【问题描述】：

我继承了一些仍在进行中的代码。我认为它有一个明显的架构问题：

它有一个包含所有领域实体的项目（领域层）和一个包含所有应用服务的项目（应用层）。应用层依赖于领域层。到现在为止还挺好。然后是第三个项目，其中包含应用层的所有视图模型。我将其称为视图模型层。很好。

问题是，我已经意识到领域层对视图模型层具有积极的依赖关系。它是什么，他们在这里为每个实体放置了一堆元数据，主要是各种字符串字段的最大长度，并且域实体和视图模型都引用了这些常量值。

我很确定以这种方式让您的域模型依赖于视图模型是非常糟糕的。我发现这一点是因为我想将域模型用于视图模型中的某些东西，但我发现我不能这样做，因为它会导致循环引用。

所以我的问题是：这种架构有多糟糕？或者我真的错了，这根本不是问题。我实际上找不到答案，可能是因为它被认为是如此明显。此外，人们通常对域实体和视图模型都通用的字段元数据（如最大长度）做什么？在多个地方写出来似乎很浪费。

我正在使用带有 Angular 客户端的 c# MVC 来实现它的价值。

提前致谢。

【问题讨论】：

【解决方案1】：

清洁架构推动我们分离稳定的业务规则（更高级别的抽象）来自不稳定的技术细节（较低级别的细节），定义清晰的边界。主楼 block 是依赖规则：源代码依赖必须只指向向内，朝向更高级别的模块。更高级别的模块不应该依赖于较低级别的模块。

您的领域模型不应依赖于视图模型。它打破了 Robert C. Martin 最重要的清洁架构规则。

这种架构有多糟糕？

这和它产生的问题一样糟糕。您已经指出的第一个 - 您不能在 View Models 模块中引用 Domain Models 模块。领域模型足够复杂，因为它解决了领域问题。您不应该通过引用细节（如视图模型）来增加额外的复杂性。另一个我能想到的问题，你的依赖越多，你的领域模型就越难测试。

另外，人们通常对字段元数据做什么（比如最大长度）域实体和视图模型都有哪些共同点？似乎把它写在多个地方真是浪费。

验证规则可以有不同的来源，例如：

您应该考虑您拥有的每条验证规则，并决定它的来源。如果验证规则在业务规则方面有意义，我会将其放入域模型中。也许有一些验证规则不应该出现在您的域模型中？希望对您有所帮助:)。

也可以看看这篇文章：Data validation

【讨论】：

我强烈支持这个答案以及阅读“清洁架构”的隐含建议。
感谢您的回答。自然，我正在尝试确定是否值得我花时间进行更改，我知道这是一个很难回答的问题，因为您只能事后才真正知道它是否值得。大多数字段元数据只是任意长度限制。所以我不确定那个“来自”的地方。他们是否有限制使用的存储空间？因此它们来自数据库。或者他们在那里鼓励用户输入更简洁的描述，在这种情况下，他们是业务逻辑。无论哪种方式，我都不认为视图模型是处理此类事情的正确位置。