domain driven design - Where to implement data access for an aggregate root entity accessor method -
i have aggregate root named account
, entity named contact
can accessed through method on root: account.getcontactbyid(string id)
. access aggregate root through repository, data access logic accounts storage resides there.
where should data access logic accessing contact
entity reside? examples see show account.getcontactbyid
method searching in-memory collection. in case, account
can reference thousands of contacts
not want prefetch memory. so, given access data storage required when method called, implement access in:
- the
account.getcontactbyid
method? spread direct access storage outside of repositories , introduce tight coupling. - the
accountrepository
, can calledaccount
aggregate? seem exposecontact
entities directly other user of repository, violates evans' rules. - another repository, such
contactrepository
? in case have repository entity not aggregate root. - other?
the comments @plalx pointed me in right direction. i'm posting resolution here answer others might have same type of question.
after reading couple of articles vernon modeling aggregates (you can find articles here , here) came conclusion letting compositional structure drive me toward bad model. because contact
relates account
not enough put them in same aggregate. vernon:
designing aggregates more consistency boundaries. reference between 2 aggregates not mean in same consistency boundary, , therefore single aggregate 1 root.
he explains how doesn't scale, in part because of issue hitting, using sprint tracking system example:
keeping performance , scalability in mind, happens when 1 user of 1 tenant wants add single backlog item product, 1 years old , has thousands of backlog items? assume persistence mechanism capable of lazy loading (hibernate). never load backlog items, releases, , sprints @ once. still, thousands of backlog items loaded memory add 1 new element large collection.
he makes helpful comments how single entity aggregates value types preferred when possible, instead of large-cluster multi-entity aggregate model building, , separate aggregates should reference 1 identifiers only. suggests application services means resolve associations between aggregates.
so, in end, separated contact
, account
different aggregates, application service resolve association.
Comments
Post a Comment