Sometimes when working on applications, especially when trying to follow the appropriate OOD and DDD patterns, we get domain classes such as Customer . Then we have some repository that will load this object, and everything will be fine and clean.
Then the application grows in complexity, and we begin to optimize performance. We often find ourselves in situations where we really do not need to load, say, a list of complete Customer objects, but perhaps just identifiers and names or a small subset of properties (for example, to display in a grid)
Solutions I've often seen include:
Non-loaded domain objects, therefore, we will mainly use the Customer class, but we will use a separate repository method to load them, and this repository method will load only the required fields from the database and fill in the corresponding properties in the objects. The remaining Customer fields will remain only by default. This is a simple solution, but can lead to numerous errors if the developer (or existing code) expects to load certain properties.
The purpose of the class in which we create classes, such as CustomerIdName , CustomerInfo , CustomerHeader , which contain only the properties we need. Such an approach could create a large number of classes, but with a thorough subclass can be done. It seems to take away from the ubiquitous concept of language language.
So, is there some kind of generally accepted agreement for dealing with people in the DDD world? I tried to do this, but could not find anything authoritative.
Or maybe this is just a known limitation of the classic DDD and CQRS approach, or would other approaches be better in these scenarios?
source share