DDD Architecture in a MVC web application

Question

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

Questions:

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?

• Robert Harvey: DDD is not an architecture.

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.