Is there a common DDD pattern to deal with under-loading of domain objects?

Question

Sometimes when working on applications, especially when trying to follow proper OOD and DDD patterns, we end up with domain classes such as Customer. Then we have some repository that will load this object, and everything is nice and clean.

Then the application grows in complexity, and we start optimizing for performance. We often find ourselves in situations, where we do not really need to load, say, a list of full Customer objects, but maybe just IDs and names, or a small subset of properties (for example to display in a grid)

Solutions that I have often seen include:

1. Under-loading domain objects, so basically we would still use Customer class, but we would use separate repository method to load those, and that repository method would load from database only required fields, and populate corresponding properties in objects. Remaining Customer fields would just remain at their default values. This is simple solution, but can lead to many errors if developer (or existing code) expects certain properties to be loaded.

2. Purpose-classing where we create classes such as CustomerIdName, CustomerInfo, CustomerHeader that contain only properties we need. This approach could create a large number of classes, but with careful subclassing is workable. It seems like it takes away from ubiquitous domain language concept though.

So is there some generally agreed convention to handle those in DDD world? I tried to google this, but were not able to find anything authoritative.

Or maybe it is just a well-known limitation of classic DDD approach and CQRS or other approaches would be better in those scenarios?

Answer 1

I think second approach is the way to go. We are doing that way in our projects but only for read only DTO classes. As long as you are not using them for insert/update that is just fine I guess.

There is also that answer you maybe interested in:

Answer 2

It's a well-known limitation of DDD and CQRS is a very good approach to solve it.

CQRS on the read side is basically solution #2 with all necessary precautions to avoid confusing Read Models with modifiable domain Entities : no Repositories for them, readonly classes, etc.