What if, however, a particular view requires the display of data contained in the associated aggregate? The aggregate itself can no longer be used but this is where the read-model pattern comes to the rescue. This also simplifies the model and transitively the mappings. Recent DDD guidance suggests that aggregates should reference other aggregates using only the identity instead of direct association. This is perhaps the central advantage from the DDD perspective - keeping the aggregates and entities pure and Occam-esque. Next is simplicity - there is no simpler way of pulling data from a database - no ORM, no mapping magic, no problem! Furthermore, the developer isnвЂ™t faced with coercing the order entity class to match the shape of the query at hand. The first of course is performance since relational databases are very adept at these types of queries. This trivial pattern boasts several advantages.

Alternative names for these types of objects are reporting objects, views, projections and probably something else IвЂ™m not thinking of at the moment.

Accordingly, these types of classes are called read-models. Instances of this class are meant for read-only purposes such as for display in a GUI. Note that this class contains no behavior and is read only. An alternative solution, one that is accordance with KISS, is to create an aggregating database query and map the results to simple, read-only objects: While NHibernate and other ORMs offer solutions to this problem, these solutions are relatively complex and can become a performance burden for both the database and the ORM. For retrieving a single instance of an order entity this approach is acceptable however for collections of orders, as in the case of the GetMostRecent method on the order repository, this results in the select N+1 problem. This can be achieved using several fetching strategies, including joining the order line items table or issuing a second select statement to the database. When retrieving an order entity, the repository must also retrieve the order line items in order for the entity to be complete. The relationship between an order and an order line item is one-to-many and in a relational model there would be a table for the orders and a table for the order line items related by a foreign key. However if implemented using an ORM such as NHibernate certain caveats arise even in this simplistic scenario. In C# the corresponding classes might look something like this:ДЇrom a client perspective the repository contract satisfies the requirements. The order total is a sum of the constituent line item totals and the tax and shipping charges. The requirement for this type of summarizing information depends on the project, but is commonplace in applications involving any type of GUI.Д¬onsider the standard order model with an order entity containing a collection of line items. The basic premise of this approach is to leverage the underlying database, a relational database in particular, for what itвЂ™s good at - namely aggregation, filtering, and projection. This particular responsibility is not well explored or developed and as a result is often overlooked in practice. Eric Evans attributes another potential responsibility to a repository in the blue book:ДЄlthough most queries return an object or a collection of objects, it also fits within the concept to return some types of summary calculations, such as an object count, or a sum of a numerical attribute that was intended by the model to be tallied.

Repositories are typically used to provide access to aggregate roots, entities and less frequently to value objects. Domain-Driven Design espouses the repository pattern as a way to persist and reconstitute domain objects from a persistent store such as a database.

Domain driven design model