Styjun

I have been reading a lot about SOLID and Domain Driven Design, then the debate on Anemic Domain Models and Rich Domain Models. I personally prefer the approach where an object will encapsulate its own domain knowledge, however as there is seemingly some difference of opinion I have some questions:

1. Depending on the type of system, the main domain classes could get quite big, even if the logic of the methods are in separate classes. Is it generally acceptable that Single Responsibility Principal is ignored here, or is there a way of encapsulating say an Order with 50 fields and 50 methods, into a nice structure that does not leave you with a 1mb class, or is this acceptable given the encapsulation approach?


2. Is there any guideline or rule of thumb on what should still go into a Domain Service or even Domain Factory, while trying to maintain an Rich Domain Model and encapsulation?

SRP always applies. I would ask myself if that entity makes sense as a whole, or it would be easier to understand it and work with it if you are able find some internal substructure and split it that way.

If you have a 50-fields order, it might actually be a classical case where bounded contexts apply, that is where an order can be viewed differently by different subsystems, and only parts of the order are needed by each subsystems.

For "Domain Factory" the rule of thumb is that it contains anything related to the object creation.

For "Domain Service" it seems to be a stateless pile of logic that doesn't fit logically in entities. see this.

P.S. I don't think that a 1 MB class (10K lines of code or more) is ever acceptable by any software design methodology (unless it is generated code, and thus is not intended for humans). Unfortunately sometimes the code reaches that state accidentally, due to lack of design planning, fear of refactoring, or deliberate omission (a decision to postpone the tech debt). That depends on the app and programming languages, but my personal rule of thumb is to start worrying and improve the design if the class reaches 1K lines, or even a bit before that.

It is never acceptable to have an object that has 50 methods and using "rich" objects don't really lead to this. If you have that, you can use the standard methods of refactoring to solve the problem.

The SRP has many interpretations, but in one of these it means "things that change together should be together". I.e. it is "legal" to have cohesive things together in one class. Here are some more details on this: Single Responsibility Principle.

If you do "rich" modeling, i.e. object-orientation, then Services should not be used. Services are stateless scripts (i.e. procedures) that usually access data from other objects do something with it and put it back into other objects. Aside from conceptual/modeling problems, it leads to all sorts of practical problems too. Here is a presentation with a little more details: Object-Oriented Domain-Driven-Design.

Also, I went through Vaughn Vernon's repository looking for how/why Services are used and I found none with functionality that didn't have a better place in a real object.

Factories are a bit different, they are a purely technical thing to abstract construction and should contain only construction code.