我继承了一些仍在进行中的代码。我认为它有一个明显的架构问题：
它有一个包含所有域实体的项目(域层(和一个包含所有应用程序服务的项目(应用程序层(。应用层依赖于域层。目前为止，一切都好。然后是第三个项目，其中包含应用程序层的所有视图模型。我将其称为视图模型层。好。
问题是，我已经意识到域层对视图模型层具有主动依赖关系。它是什么，他们在这里为每个实体放置了一堆元数据，主要是各种字符串字段的最大长度，并且域实体和视图模型都引用了这些常量值。
我很确定以这种方式让您的领域模型依赖于视图模型是非常糟糕的。我发现这一点是因为我想将域模型用于视图模型中的某些内容，并发现我不能，因为它会导致循环引用。
所以我的问题是：这个架构有多糟糕？还是我真的错了，这根本不是问题。我实际上找不到答案，可能是因为它被认为太明显了。 此外，人们通常如何处理域实体和视图模型通用的字段元数据(如最大长度(？在多个地方写出来似乎是一种浪费。
我正在使用带有角度客户端的 c# MVC 来衡量它的价值。
提前谢谢。
干净的架构促使我们分离稳定的业务规则 (更高层次的抽象(来自易失性技术细节 (较低级别的详细信息(，定义明确的边界。主楼 block 是依赖关系规则：源代码依赖关系必须仅指向 向内，向更高层次的模块。更高级别模块不应该 取决于较低级别的模块。
域模型不应依赖于视图模型。它打破了罗伯特·C·马丁(Robert C. Martin(最重要的清洁建筑规则。
这个架构有多糟糕？
这和它产生的问题一样糟糕。您已经指出的第一个 - 您不能在视图模型模块中引用域模型模块。域模型足够复杂，因为它解决了域问题。不应通过引用详细信息(如视图模型(来增加额外的复杂性。我能想到的另一个问题是，你拥有的依赖项越多，测试你的领域模型就越困难。
另外，人们通常对字段元数据做什么(如最大长度( 域实体和视图模型共有哪个？似乎 在不止一个地方写出来是一种浪费。
验证规则可以有不同的来源，例如：
- 技术数据库限制
- 业务规则
- 图形用户界面友好性
- 其他？
您应该考虑您拥有的每个验证规则，并决定它的来源。如果验证规则在业务规则方面有意义，我会将其放在域模型中。也许有一些验证规则不应该出现在您的域模型中？希望它对你有所帮助:)。
另请查看本文：数据验证