I'm trying to build an architecture where I have a Domain project with all my domain models, an Infrastructure project with my Services and Infrastructure.Entity with my Repositories and entities.

However, I'm a little confused on what's the best way to pass objects between the different layers.

The presentation layer only knows about the domain and service layer/infrastructure, and passes the domain objects to the service. And that's where I'm in doubt.

Let's say I have:

  • DomainProduct
  • EntityProduct
  • ProductController
  • ProductService
  • ProductRepository

Question: Where do I map the objects between domain models and entities? I call the servie with a domain model, but does the service call the repository with a domain model, or do I map it to an entity and call the repository with that?

  1. Controller -> Domain model -> Service
  2. Service -> Domain model -> Repository


  1. Service -> Entity -> Repository

(and vice-versa)

Case: Deleting a product

Here I would just call the service from the controller with the ID of the product that needs to get deleted. Then the service either:

  • Calls Delete(id) on the repository


  • Gets the product from the repository by the ID
  • Calls the delete method on the repository with the model?

However, isn't that a voilation in DDD? Should I first get the DomainProduct from the service layer, and then call Delete with that DomainProduct? That just seems redundant an unnecessary.

I'm a little confused on how it's done best. I like the ID way the most, and passing entities between the service and repository. But I think it's a violation.

Can you help me?

  • Repositories are part of Domain model. Repositories take and return domain entities. If repository is implemented using plain SQL or if it uses entities inside it is it's implementation detail. – Euphoric Sep 11 '16 at 11:23

If you look at the CQRS pattern you'll note that domain operations boil down to commands. In this case I'd see it completely fine to define a delete command as just requiring the ID. Also using this pattern allows you complete flexibility in how the data is represented and does not tie one down to how the domain entities are structured.

Then there might be some cases where an operation against a domain would require it to be deleted. Say you have an email queue and an item reaches the send threshold. One could then argue that you can potentially check if the threshold was reached and just provide the object to the repository and have it be deleted that way.

One thing that I would be weary about would be to allow the controller to access the Domain objects directly.Ideally you'd rather have domain manipulations be done by the business layer and just have the Controllers (which should be responsible for UI rather) be able to communicate accordingly with the business layer.

| improve this answer | |

Ideally, you have separate domain models and data transfer objects (DTO). The domain model is a model per layer or domain. For example, the UI layer and the business logic layer should have their own domain objects.

You use DTO's to pass "data" between the layers.

[UI Layer] <- UserDto -> [Business logic layer]

The act of converting the domain objects to DTO's and back again on the other side is generally called "object mapping". Libraries like AutoMapper are used to simplify the process.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.