I am putting together a web application using DDD however am strugleing to put the text book DDD model into a real world MVC application.

I currently have these layers:

Controllers > ViewModelsBuilders > Domain Services > Aggregates, Remote API's and Repositories

  • Controllers
    The action results need a view model
  • ViewModelsBuilder
    These build the view model needed from a set of Domain Services.
  • Domain Services
    These are the entry point to my domain and use Aggregates (for complex domain logic) passing in data from Remote API's and Repositories
  • Aggregates and Entities
    These are all limited to the scope of the assembly and contain the business logic


  1. Is this the correct structure, should it be the domain services or the view model builders pulling everything together?
  2. The objects returned from the Domain Services should these be simple DTO or the actual entities, hiding the methods with access levels?
  3. Should the Domain services be the gatekeeper or should the view model builders access the aggregate root, repositories etc?
  • DDD is not an architecture. Commented Sep 9, 2016 at 14:56

1 Answer 1


The approach that I have used in the past that can be applied in MVC & WebAPI projects follows:

  • End Point (Controllers, ApiController) return ViewModels (DTOs)
  • Business Layer / Application Layer / Domain Service - return application data
  • Data Access Layer - Repository Pattern - returns DB Model Entities

Each layer is responsible for its own data.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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