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

Question

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

1. 根据系统的类型，即使方法的逻辑位于单独的类中，主领域类也可能变得很大。在这里忽略“单一责任主体”通常是可以接受的，还是有一种方法可以将具有50个字段和50个方法的Order封装为一个不会给您留下1mb类的漂亮结构，或者在封装的情况下可以接受方法？
2. 在尝试维护Rich Domain Model和封装时，对于仍应包含在Domain Service或Domain Factory中的内容是否有任何指导或经验法则？

Answer 1

SRP始终适用。我会问自己，该实体从整体上看是否有意义，或者，如果您能够找到一些内部子结构并将其拆分，则更容易理解和使用它。

如果您有一个50字段的订单，那么实际上可能是一个经典的案例，其中应用bounded contexts，即在该订单中不同子系统可以不同地查看该订单，每个子系统只需要部分订单子系统。

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

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

P.S。我认为1 MB类（10K行代码或更多）不能被任何软件设计方法接受（除非它是生成的代码，因此不适合人类使用）。不幸的是，有时由于缺乏设计计划，担心重构或故意遗漏（推迟技术债务的决定），代码偶然到达了该状态。这取决于应用程序和编程语言，但是我个人的经验法则是开始担心，如果类达到1K行甚至在此之前达到一点，就会改进设计。

Answer 2

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

SRP有许多解释，但是在其中一种解释中，它意味着“一起改变的事物应该在一起”。即在一个班级中将具有凝聚力的东西放在一起是“合法的”。以下是有关此内容的更多详细信息：Single Responsibility Principle。

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

此外，我经历了Vaughn Vernon's repository，以寻找如何/为什么使用服务，却发现没有一个功能在实际对象中没有更好的位置。

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