富域模型是否意味着可以接受大型域类？答案

【问题标题】：Do Rich Domain Models mean large domain classes are acceptable?富域模型是否意味着可以接受大型域类？
【发布时间】：2019-08-16 04:57:56
【问题描述】：

我已经阅读了很多关于 SOLID 和域驱动设计的文章，然后是关于贫血域模型和富域模型的辩论。我个人更喜欢对象封装自己的领域知识的方法，但是由于似乎存在一些意见分歧，我有一些问题：

根据系统类型，主域类可能会变得相当大，即使方法的逻辑位于不同的类中。在这里忽略 Single Responsibility Principal 是否通常可以接受，或者是否有一种方法可以将具有 50 个字段和 50 个方法的 Order 封装成一个不会给您留下 1mb 类的良好结构，或者考虑到封装，这是否可以接受方法？
在尝试维护丰富的域模型和封装时，是否有任何指南或经验法则来说明域服务甚至域工厂仍应包含哪些内容？

【问题讨论】：

stackoverflow.com/search?q=Rich+vs+Anemic+Domain+Model
DDD 是设计模式和技术的集合，除其他外，它可以防止您最终获得 50 个字段怪物类。域模型不是你涂在数据库模型猪身上的口红。如果你最终得到一个 50 个字段的怪物实体，请问自己什么聚合不变量必须在事务上保持一致，这取决于 50 条数据。

标签： architecture domain-driven-design software-design solid-principles

【解决方案1】：

SRP 始终适用。我会问自己，该实体作为一个整体是否有意义，或者如果您能够找到一些内部子结构并以这种方式拆分它，那么它会更容易理解并使用它。

如果您有 50 个字段的订单，它实际上可能是一个经典案例，bounded contexts 适用，即不同子系统可以以不同方式查看订单，每个子系统只需要部分订单。

对于“域工厂”，经验法则是它包含与对象创建相关的任何内容。

对于“域服务”，它似乎是一堆无状态的逻辑，在逻辑上不适合实体。 see this.

附：我不认为任何软件设计方法都可以接受 1 MB 类（10K 行或更多代码）（除非它是生成代码，因此不适合人类使用）。不幸的是，有时由于缺乏设计规划、害怕重构或故意遗漏（推迟技术债务的决定），代码会意外地达到该状态。这取决于应用程序和编程语言，但我个人的经验法则是，如果课程达到 1K 行，甚至更早一点，就开始担心并改进设计。

【讨论】：

【解决方案2】：

拥有一个拥有 50 种方法的对象是绝对不能接受的，而使用“丰富”的对象并不会真正导致这种情况。如果你有，你可以使用标准的重构方法来解决问题。

SRP 有多种解释，但在其中一种解释中，它的意思是“一起改变的事物应该在一起”。 IE。将凝聚力的事物放在一个类中是“合法的”。以下是有关此的更多详细信息：Single Responsibility Principle。

如果您进行“丰富”建模，即面向对象，则不应使用服务。服务是无状态的脚本（即过程），通常从其他对象访问数据并对其进行处理并将其放回其他对象。除了概念/建模问题外，它还会导致各种实际问题。这是一个包含更多细节的演示文稿：Object-Oriented Domain-Driven-Design。

另外，我通过Vaughn Vernon's repository 寻找如何/为什么使用服务，但我发现没有一个具有在真实对象中没有更好位置的功能。

工厂有点不同，它们是抽象构造的纯技术性东西，应该只包含构造代码。

【讨论】：