Suppose we have such an aggregate in our domain that it is stored in table hierarchy three levels deep. Let's denote domain objects as Order-OrderItems-ItemAttributes.
Let's also assume that we use the Repository pattern on our Data layer.
Repository contains method GetAll that returns the listing of Orders.
We follow REST on our service layer, hence, we use
GET /orders to get the listingGET /orders/{Id} to get the concrete OrderThe listing contains only the basic fields of each Order without details, however, the query by id returns bigger object.
As materialization of one Order is expensive operation, we don't like the fact that we get full aggregates just to send a couple of fields to a client. On the other hand, we try follow the reasonable rule that repository must return only fully initialized aggregates.
How could we solve this difficulty?
Aside from CQRS as suggested by others, would a simple Lazy loading be a good solution to this problem? Order items will not be loaded if they are not accessed. Or a dedicated OrderSummary/OrderStatus domain object if you can not use lazy loading?
Also it is always worth reconsidering whether a heavy aggregate is really needed. There may simply be no domain rules that call for it. Life cycle for example is a well known 'wrong reason' for having heavy aggregates (like Group->User, or Product->BacklogItem). Highly recommended read on this subject: Aggregate design.