In DDD, are collection properties of entities allowed to have partial values?

Question

In Domain Driven Design are collection properties of entities allowed to have partial values?

For example, should properties such as Customer.Orders, Post.Comments, Graph.Vertices always contain all orders, comments, vertices or it is allowed to have today's orders, recent comments, orphaned vertices?

Correspondingly, should Repositories provide methods like

GetCustomerWithOrdersBySpecification
GetPostWithCommentsBefore

etc.?

Answer 1

I don't think that DDD tells you to do or not to do this. It strongly depends on the system you are building and the specific problems you need to solve.

I not even heard about patterns about this.

From a subjective point of view I would say that entities should be complete by definitions (considering lazy loading), and could completely or partially be loaded to DTO's, to optimized the amount of data sent to clients. But I wouldn't mind to load partial entities from the database if it would solve some problem.

Answer 2

Remember that Domain-Driven Design also has a concept of services. For performing certain database queries, it's better to model the problem as a service than as a collection of child objects attached to a parent object.

A good example of this might be creating a report by accepting several user-entered parameters. It be easier to model this as:

CustomerReportService.GetOrdersByOrderDate(Customer theCustomer, Date cutoff);

Than like this:

myCustomer.OrdersCollection.SelectMatching(Date cutoff);

Or to put it another way, the DDD model you use for data entry does not have to be the same as the DDD model you use for reporting.

In highly scalable systems, it's common to separate these two concerns.