DDD – CRUD Operations in Domain-Driven Design

asp.net-mvcdesign-patternsdomain-driven-designmvcpatterns-and-practices

I'm designing an application with DDD. I'm moving from flat POCO objects to strong domain models, so my question is:

Would I have to call my basic CRUD operations (located in my repository layer) from controllers directly, without passing through the domain layer? I can't see any added value to doing that, but I'm not sure if it's inside the DDD practices make that direct call.

Best Answer

The typical entry point for this in DDD is an Application Service. Application services orchestrate calls to repositories and domain objects. They also know about the current execution state and often control the overarching business transaction through a unit of work that is committed at the end of the service method.

For example :

Create new domain object
Add it to Repository
Commit UoW

or

Get domain object from Repository
Modify it
Commit UoW

etc.

The application service can be called from a Controller. In some implementations it is the controller, when people don't want to bother an additional abstraction layer. But that can lead to a Fat Controller.

my basic CRUD operations (located in my repository layer)

While C, R and D are part of a Repository interface, U doesn't have to if you have a Unit of Work. Update of all changed domain entities in the UoW will be done automatically on UoW.Save().

Related Topic