Question

Recently finished reading Eric Evans Domain Driven Design (very informative, very enjoyable) however come to first major project since completing the book and got the issue how to handle the domain model save?

I appreciate the use of services / repositories and how they can aid the model but how would they handle the model save?

My previous domain model saves would follow the following method call structure;

ParentClass.Save {

ParentClassDB.Save

ChildObject1.Save

       ChildObject1DB.Save

ChildObject2.Save

       ChildObject2DB.Save  
  etc etc 

}

Does the service take control of calling the appropiate save routines on the child objects?

Was it helpful?

Solution

In DDD, the domain entity doesn't take care of its persistence. You should not have a Save() method on it, ideally.

Your repository will have such a Save method, that takes an entity instance in parameter:

public class PersonRepository
{
   //...

   public void Save(Person person)
   {
      this.dataContext.Save(person);
   }

   //...
}

Depending on your stack, an ORM will handle the object saving, or you will end by constructing a query to save the person, or you will populate stored procedure parameters with from your instance values, etc.

If I understood correctly what you did, it may be necessary to move the persistence logic you put in the domain entities elsewhere, probably in repositories, or in the DAL used by your repositories.

OTHER TIPS

Do you use Aggregate roots? They are responsilbe for saving their entities.

If there is lots of modifications going on one way could be to encapsulate that logic in a domain service and have the service handle the saves through the Aggregate roots.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top