CODEWITHSUNDEEP
architecturedomain-driven-designmodeling
acid
acid

Reputation: 2149

Presentation properties on domain models?

In the context of DDD and domain modeling, let's say I have a Product class which has id, price properties which I use extensively in my business logic. However, my presentation layer also requires an image property. I don't think I should put that in my domain layer (since it's not used nowhere by my business logic), however I am trying to think where is the right place to put it. Should I create a ProductViewModel and assemble it from Product class somewhere? Should the assembly be done in the application layer? What are the options here?

Upvotes: 2

Views: 265

Answers (2)

L-Four
L-Four

Reputation: 13531

Typically I always separate queries from commands.

Commands are sent from consumer (for example a client application) to my service layer. The service layer then routes the request to the application layer, where the domain and infrastructure layers are used to execute the request.

Queries are also sent to my service layer, but then the application layer bypasses the domain layer and query the database directly; so it doesn't use the domain entities but it has its own query entities (presentation entities if you like); which are different than the domain entities.

If I project your situation to this architecture, then it would be the application layer that is responsible for constructing the query result entities, which include the image. As the domain layer is not used for queries, domain entities don't know about the image.

You don't give much details about how your architecture looks like (what entities are you exposing to your presentation layer? Domain entities themselves, or DTO's? look here), and it seems you don't have this kind of separation, but the same concept applies anyway: if image is a presentation concern, don't add it do your domain entities. A valid option could be to create a view model that contains the image property, and your controller would be responsible to construct it properly.

Upvotes: 0

Alexey Balchunas
Alexey Balchunas

Reputation: 400

Referring to Martin Fowler:

One case where it is useful to use something like a DTO is when you have a significant mismatch between the model in your presentation layer and the underlying domain model. In this case it makes sense to make presentation specific facade/gateway that maps from the domain model and presents an interface that's convenient for the presentation. It fits in nicely with Presentation Model. I hope to talk about this more in the new volume. This is worth doing, but it's only worth doing for screens that have this mismatch (in this case it isn't extra work, since you'd have to do it in the screen anyway.)

So it seems to be okay to create some kind of ProductViewModel.

Concerning the place where it should be created Martin Fowler says that the right way is to create some kind ProductViewModelAssembler which knows how to load, save and update the model.

In my last project we managed not to use assemblers and just created constructors in DTOs that accept all necessary data to be created. But you still need to write some code saving and updating underlying domain models.

Upvotes: 1

Related Questions