If not in the Repository, then where do you shape your Aggregate(s) into objects suitable for your presentation layer?Ī dedicated DTO Assembler has the single responsibility of mapping (as in Mapper) the attributes from the Aggregate(s) to the DTO.Ī DTO Assembler can live in an Application Service that is a client of your Repository. Still, the DTO needs to be assembled somewhere… The DTO Assembler It is in the DTO’s job description to be a carrier of Aggregate state to the Presentation Layer.
That’s not in the Repository’s job description. With these definitions, it’s clear that a Repository’s responsibility lies in persisting the state of Aggregates, not sharing the state of Aggregates with the Presentation Layer. “designed to hold the entire number of attributes that need to be displayed in a view.” - Vernon When used to move data from the Domain Layer to the Presentation Layer, a DTO is: “carries data between processes in order to reduce the number of method calls” - Fowler ”…a cohesive set of responsibilities for providing access to the roots of AGGREGATES from early life cycle through the end” - EvansĪ DTO was originally defined to be used in conjunction with a Remote Facade. Should the projection from Aggregate(s) to DTO be done inside your Repositories? Job DescriptionsĪ Repository should only really concern itself with the persistence of Aggregates.
Your architecture is effectively layered, but you find yourself looking for the right place to turn your Aggregates into DTOs ( Data Transfer Objects). Problem is, the Presentation Layer needs objects of a different shape than your Domain Layer Aggregates.īy different shape, I mean that this layer might need data combined from multiple Aggregates, or only portions of an Aggregate. Entity Framework, into an MVC view or a Web API controller. Imagine you have a nicely designed Domain Layer that uses Repositories to handle getting Domain Entities from your database with an ORM, e.g.
A Better Way to Project Domain Entities into DTOs
0 kommentar(er)
