我一直在阅读很多关于SOLID和领域驱动设计的内容，然后是关于贫血领域模型和富域模型的辩论。我个人更喜欢这样一种方法，即一个对象将封装自己的领域知识，但是由于看似有些意见不同，我有一些问题：
SRP始终适用。我会问自己这个实体是否整体有意义，或者如果你能够找到一些内部子结构并以这种方式拆分，那么理解它并更容易理解它。
如果您有50个字段的订单，它实际上可能是bounded contexts适用的经典案例，也就是不同子系统可以不同地查看订单，并且每个子系统只需要部分订单。
对于“Domain Factory”，经验法则是它包含与对象创建相关的任何内容。
对于“域服务”，它似乎是一个无状态的逻辑堆，不适合逻辑上的实体。 see this。
附：我认为任何软件设计方法都不能接受1 MB级别（10K行代码或更多代码）（除非它是生成代码，因此不适用于人类）。不幸的是，由于缺乏设计规划，担心重构或故意遗漏（决定推迟科技债务），有时代码会意外地达到该状态。这取决于应用程序和编程语言，但我个人的经验法则是，如果类达到1K行，或者甚至在此之前，我会开始担心并改进设计。
拥有50个方法的对象并使用“丰富”对象并不能真正导致这种情况，这是绝对不可接受的。如果你有，你可以使用标准的重构方法来解决问题。
SRP有许多解释，但在其中一个中它意味着“一起变化的事物应该在一起”。即在一个班级中将有凝聚力的事物放在一起是“合法的”。以下是关于此的更多细节：Single Responsibility Principle。
如果您进行“丰富”建模，即面向对象，则不应使用服务。服务是无状态脚本（即程序），通常从其他对象访问数据，然后将其放回到其他对象中。除了概念/建模问题，它还会导致各种实际问题。这是一个更详细的介绍：Object-Oriented Domain-Driven-Design。
此外，我通过Vaughn Vernon's repository寻找服务的使用方式/原因，我发现没有任何功能在真实对象中没有更好的位置。
工厂有点不同，它们是抽象构造的纯粹技术性的东西，应该只包含构造代码。