Mvvm 域模型依赖于视图模型有多糟糕？

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

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

问题是，我已经意识到域层对视图模型层具有活动的依赖性。实际上，他们在这里为每个实体放了一堆元数据，大部分是各种字符串字段的最大长度，域实体和视图模型都引用了这些常量值

我敢肯定，让您的域模型以这种方式依赖于视图模型是非常糟糕的。我发现这是因为我想在视图模型中使用域模型，但发现我不能，因为它会导致循环引用

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

我正在使用c#MVC和angular client，这是值得的

提前谢谢

干净的体系结构促使我们分离稳定的业务规则 （高级抽象）来自易变的技术细节 （较低级别的详细信息），定义清晰的边界。主楼 块是依赖项规则：源代码依赖项只能指向 向内，朝向更高级别的模块。高级模块不应该这样做 取决于较低级别的模块

您的域模型不应该依赖于视图模型。它打破了罗伯特·C·马丁最重要的清洁建筑规则

这种架构有多糟糕

这和它产生的问题一样糟糕。您已经指出的第一个问题是，您不能在视图模型模块中引用域模型模块。领域模型由于其解决的领域问题而变得足够复杂。您不应该通过引用细节（如视图模型）来增加额外的复杂性。我能想到的另一个问题是，依赖关系越多，测试域模型就越困难

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

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

• 技术数据库限制
• 商业规则
• GUI友好
• 其他的

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

---

再看看这篇文章：

你的意思是域模型依赖于视图模型？因为你文章的标题让我想到了相反的东西。你说得对，谢谢。更改了标题。我强烈支持这个答案，并暗示建议阅读“干净的架构”。谢谢你的回答。当然，我正在努力弄清楚是否值得我花时间去改变它，我知道这是一个很难回答的问题，因为你只能事后才知道它是否值得。大多数字段元数据只是任意长度的限制。所以我不确定这是从哪里来的。它们是否用于限制存储空间的使用？因此，它们来自数据库。或者它们是为了鼓励用户输入更简洁的描述，在这种情况下，它们是业务逻辑。不管怎样，我不认为视图模型是处理此类事情的正确位置。