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

Question

我读了很多关于SOLID和的文章，然后是关于贫血领域模型和富领域模型的辩论。我个人更喜欢对象封装自己领域知识的方法，然而，由于似乎有一些不同的意见，我有一些问题：

1. 根据系统类型的不同，即使方法的逻辑位于单独的类中，主域类也会变得相当大。在这里忽略单一责任主体是普遍可以接受的，还是有一种方法可以将一个包含50个字段和50个方法的订单封装到一个不给您留下1mb类的好结构中，或者考虑到封装方法，这是否可以接受？
2. 在试图维护富域模型和封装的同时，对于仍然应该进入域服务甚至域工厂的内容是否有任何指导原则或经验规则？

Answer 1

SRP总是适用。我会问自己，这个实体作为一个整体是否有意义，或者如果你能够找到一些内部的子结构并以这种方式分割它，那么理解它和与它一起工作就会更容易。

如果您有一个50字段的顺序，那么它实际上可能是一个典型的有界上下文应用案例，即一个顺序可以被不同的子系统以不同的方式看待，并且每个子系统只需要部分的订单。

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

对于“域服务”，它似乎是一堆不符合实体逻辑的无状态逻辑。看看这个。

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

Answer 2

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

SRP有很多解释，但在其中一种解释中，它的意思是“变化在一起的东西应该在一起”。也就是说，把有凝聚力的东西集中在一起是“合法的”。下面是关于这一点的更多细节：单一责任原则。

如果您进行“富”建模，即面向对象，那么就不应该使用服务。服务是无状态脚本(即过程)，通常从其他对象访问数据，并对其进行处理并将其放回其他对象中。除了概念/建模问题之外，它还会导致各种实际问题。下面是一个包含更多细节的演示文稿：面向对象的领域驱动设计。

此外，我浏览了沃恩·弗农储存库，寻找如何/为什么使用服务，我发现没有一个在实际对象中没有更好位置的功能。

工厂有点不同，它们纯粹是抽象建筑的技术问题，应该只包含建筑代码。