Search code examples
domain-driven-designddd-repositories

DDD: How to handle "view" objects


If we use an Order as an Aggregate Root (AR) and OrderLines as non-root Aggregates, how do you handle the case where performance is an issue?

I am using Order/OrderLine as they are a familiar enough part to be in all our "Ubiquitous Language". So please play along that my "Order" is computationally difficult to store and more so to retrieve. When not using DDD, it would be common to "de-normalize" those into a "View". With DDD, might one create an OrderView domain object and use the Order AR to write, and the OrderView AR to read? How have others handled this situation?

Thanks in advance for any advice.


Solution

  • We handle this by creating simple data transfer objects which get populated in an application handler by an underlying SQL view which is comprised of data from our underlying domain entity tables. We've found this works very well and have had no issues. I wouldn't call this CQRS since we are using the same model for both commands and queries, but maybe you could call it CQRS-lite. I would strongly recommend you do not create view objects in your domain layer. It gives you no real value, and only adds a layer of complication.