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 ??
相关问题
- Aggregate to JPA Entity mapping
- Complex DTO structure
- How to make POCO work with Linq-to-SQL with comple
- Should we trust the repository when it comes to in
- DDD Aggregate Root / Repository Structure
相关文章
- Can Persistence Ignorance Scale?
- DDD Domain Model Complex Validation
- DDD Architecture - Where To Put Common Methods/Hel
- Reference another aggregate root in child entity?
- Domain Driven Design issue regarding repository
- how to implement DDD repository to handle a query
- How are consistency violations handled in event so
- DDD and application layer
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.
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:
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.