Perspectives of Entities

Question

Context: So, I'm trying to build a ridiculously complex domain model. Speaking with users, there are several ways to use the system (for example: one way from the point of view of the employee, the other way from the point of view of the employer). These are actually several applications that reuse the primary domain.

Question: Is it wrong to create a domain from different points of view? For example, to create a domain as it starts, business will mean creating all kinds of relationship classes that carry additional information about the object, etc. However, when launched from a certain point of view, the image is much clearer, since most of the relationship classes can be transferred to their parent.

Ideas? Rebuttals? Am I completely out of base?

Answer 1

No, this is absolutely necessary. Evan calls these “promising” limited contexts in his book.

Instead of having a truly complex domain model, try creating a simple one that will correctly address the domain in a certain way. Limited Contexts can be connected to each other to form a network of smaller, simpler, more direct domain models.

Answer 2

I do not think you should try and predefine the "primary domain" in front. Let him appear in the development process. In addition, everything that is not common to 2 (or more) perspectives should not be in the "core".

For example, create a part of the system from the perspective of the employer. This may prompt you to create objects such as Project, Task, and Client. Then create the part from the perspective of the employer. This may prompt you to create new objects and reuse Project and Task. This is when I moved "Project" and "Task" to the "main library" shared by the rest of the system.

Sometimes you find common objects, but are connected in different ways. In this case, the connection should be introduced by the context instead of being embedded with the entities themselves.