Rich Domain Models是否可以接受大型域类？

Question

我一直在阅读很多关于SOLID和领域驱动设计的内容，然后是关于贫血领域模型和富域模型的辩论。我个人更喜欢这样一种方法，即一个对象将封装自己的领域知识，但是由于看似有些意见不同，我有一些问题：

1. 根据系统的类型，主域类可能会变得非常大，即使方法的逻辑在单独的类中。通常可接受的是单一责任委托人在这里被忽略，或者是否有一种方法可以将一个包含50个字段和50个方法的订单封装成一个不会让你留下1mb类的漂亮结构，或者在封装时这是否可接受进场？
2. 在尝试维护Rich Domain模型和封装时，是否有任何关于仍应进入域服务甚至Domain Factory的指南或经验法则？

Answer 1

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

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

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

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

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

Answer 2

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

SRP有许多解释，但在其中一个中它意味着“一起变化的事物应该在一起”。即在一个班级中将有凝聚力的事物放在一起是“合法的”。以下是关于此的更多细节：Single Responsibility Principle。

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

此外，我通过Vaughn Vernon's repository寻找服务的使用方式/原因，我发现没有任何功能在真实对象中没有更好的位置。

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