could domain models be aware of repositories?

Question

May be for some domain logic implementation entities need access to repo for update/delete of self or any related entity. Does this sound right ??

Nagaland

Answer 1

No, it doesn't, at least for the question tagged with "domain-driven-design" tag. Definitely, Active Record pattern has a right to live in some systems and some people find strong coupling useful, but in DDD the proposed way is to use repositories explicitly:

Evans DDD, p.152: For each type of object that needs global access, create an object that can provide the illusion of an in-memory collection of all objects of that type. «...» Provide REPOSITORIES only for AGGREGATE roots that actually need direct access. Keep the client focused on the model, delegating all object storage and access to the REPOSITORIES.

So, in DDD, repository not only encapsulates the infrastructure code, required to access the database, but the whole idea that the objects must be stored and loaded.

If you are doing some compound actions which involve saving and loading from the database, then the services that have references to the repositories are the best candidates.

Motherwort

thanks Boris for that reply, perhaps i should elaborate a little more on where this question is coming from, please have look to this question that explains my scenario https://mcmap.net/q/2035506/-soft-delete-in-ddd and let me know what u think – Nagaland

and also since u mentioned it, i keep hearing this opinion about DDD that says do not use DDD if u are doing a normal CRUD kind of application. I find some of the general guidelines of DDD having universal whether or not I have evolved a "Ubiquitous Language"(I think there always is a UL even though the vocabulary consists of rather technical sounding terms like Insert, Update , DElete - e.g my domain expert actually uses those terms :) ) – Nagaland

@Nagaland pein's answer is fine, I'd simply introduce a Status(or State) field for the entity, and the entity would have a cancel() method which will change its status to CANCELLED, imho it has nothing to do with the repository CRUD methods. Of course when someone cancels an invoice or whatever it will be saved with the Save() method. – Motherwort

Evans states somewhere in his book that no project will exist that uses all the practices from the book, so you can't implement a 100% ddd system - it's all matter of balance and common sense anyway – Motherwort

@Nagaland I've seen your recent question so please check another answer I don't think that there are any benefits in putting much effort in adapting the frameworks, because there is always a risk to end up developing an expert system :-) – Motherwort

Answer 2

While it definitely sounds dangerous for an entity to be able to access its own repository to store or delete itself (see persistence ignorance), in some particular cases I could tolerate that an entity exceptionnally requests from a Repository another aggregate root that it doesn't already hold a reference to.

However, note that domain entities should only know about abstractions of repositories (i.e. interfaces that reside in the domain layer) and not their concrete implementations. Therefore, don't have the Domain layer reference the Infrastructure layer, but instead inject instances of concrete repositories at runtime where you need them.

And this shouldn't be the norm, anyway.

Stochastic