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

Question

我读了很多关于实体和领域驱动设计的文章，然后是关于贫乏的领域模型和丰富的领域模型的争论。我个人更喜欢一个对象封装它自己的领域知识的方法，但是，由于似乎有一些不同的意见，我有一些问题：

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

Answer 1

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

如果您有一个50字段的订单，这实际上可能是应用有界上下文的典型情况，也就是说，不同的子系统可以不同地查看订单，并且每个子系统只需要订单的一部分。

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

对于“域服务”来说，它似乎是一堆逻辑，在逻辑上不适合实体。看看这个。