For awhile now I've been practicing DDD (or at least my understanding of it). One of the challenges I faced early on, was the building grids of data for the UI and how that fits into the rules of DDD.
Here's a little background on a few things that DDD says:
- The domain entities are organized into aggregates which are to be operated on as a whole.
- Manipulation of the domain entities is done through a single entity called the aggregate root. To work with other entities in an aggregate, you must do so by using the aggregate root. For example, an Order aggregate will have an Order entity and OrderLineItem entities. You would never do operations on an OrderLineItem entity outside the context of a Order. This ensures that the business integrity for the Order is centralized doesn't leak into other areas of the system.
- Objects from one aggregate cannot hold references to objects in other aggregates.
- Aggregates have an object called a repository which is responsible for persistence and retrieve of an aggregate.
- A repository for one aggregate shouldn't return data from another aggregate.
The challenge comes in when you need show a grids to a user and also need to display related information which could come from another aggregate. For example, you may want to show a grid of invoices with a column indicating the associated customer. The Invoice entity itself may only have the CustomerID (because entities shouldn't reference entities in other aggregates) , but you need to show the user the customer name. Plus in a lot of cases, loading a list of entire aggregates is just not efficient. They'll often contain much more data than what we want to show in a grid.
The way that I dealt with this (right or wrong) is to create a new type of aggregate object which can return lists of non-mutable objects for display purposes only. I call this object a ViewProvider. The objects returned from the ViewProvider are not entities. They are not mutable and have no business logic associated with them. They are strictly for blow and go, get data to the UI. I feel this is ok because it gives you the flexible to get the data you need without compromising the intent of the aggregate. I'd be interested in knowing what other folks are doing.