Persistence encapsulated via the domain, or persistence via the Repository?

Question

If my Domain Model is not supposed to know/care about the Repository, then how does some behaviour like .UpdateOrder(...), that encapsulates a CRUD-Update, interface with the Repository? Through a Domain Service?

Ok, then my Repository has an effective CRUD-Update that's used in conjunction with my .UpdateOrder(...). That's fine. But i don't want someone to use the Update method on the Repository, i want them to go through the behaviour on the Entity (use UpdateOrder() instead). I'd prefer that in likeness to the way my Domain Model satisfies invariants - by it's design (private set properties, etc) - my Repository not expose an alternate method to "updating"/persisting the Entity.

Is this simply a access modifier problem that is solved by me not having the Update method in the Repo public. Or is there a 'better' answer? Please help me DDD ninjas.

Jefe

What does UpdateOrder do and what sort of parameters does it take? Is it literally updating the persistent storage with the values in the Entity? – Fossiliferous

UpdateOrder is a behaviour of the business model. It doesn't really matter what it takes or does except that it encapsulates the domain logic and at the end it needs to persist the changed state. – Jefe

Answer 1

The strict sequence in DDD would be:

var entityRepository = MyServiceLocator.Get<IEntityRepository>();
var myEntity = entityRepository.Load(<some criteria>);
myEntity.Change(something);
entityRepository.Save(myEntity);

The repository is always responsible for detecting/persisting all of the changes within the entity.

(btw, I'm assuming that your entity is an aggregate root)

Fanion

Thanks. Good feedback and yes the entity was a root in the example. So am i to understand that the myEntity.Change(something); in your example should not hook back into the Repository to persist the changed state, even via a Domain Service? – Jefe

Correct - the changes should be propogated to your perssitence store in the final entityRepository.Save(). If you're using a decent ORM inside your Repositories, the dirty tracking/persisting should be automatically handled for you. – Fanion

I marked this as the answer because it was the most helpful in realising the solution - not necessarily because it answered my convoluted question directly. – Jefe

Answer 2

If your domain model doesn't include persistence, then it doesn't include the operation of storing something. If your entity is something from the domain model, then it has no business persisting itself.

You say:

That's fine. But i don't want someone to use the Update method on the Repository, i want them to go through the behaviour on the Entity

But i think that's mistaken. Your domain objects have no more responsibility for persisting themselves than they do printing themselves, drawing themselves on screen, etc. Your domain class should not have a UpdateOrder method.

Now, you might not want to expose the raw repository (from your persistence implementation layer) to other code, but that just means wrapping it in something suitable. It sounds like you do have code that needs to talk about persistence, so figure out what level of discourse it needs to work at, and expose a suitable interface to it.

Gottwald