Persistence encapsulated via the domain, or persis

问题:

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.

回答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)

回答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.