domain driven design - Simple aggregate root and repository -
i'm 1 of many trying understand concept of aggregate roots, , think i've got it! however, when started modeling sample project, ran dilemma.
i have 2 entities processtype
, process
. process
cannot exist without processtype
, , processtype
has many process
es. process holds reference type, , cannot exist without it.
so should processtype
aggregate root? new processes created calling processtype.addprocess(new process())
; however, have other entities holds reference process
, , accesses type through process.type
. in case makes no sense going through processtype
first.
but afaik entities outside aggregate allowed hold references root of aggregate, , not entities inside aggregate. have 2 aggregates here, each own repository?
i largely agree sisyphus has said, particularly bit not constricting 'rules' of ddd may lead pretty illogical solution.
in terms of problem, have come across situation many times, , term 'processtype' lookup. lookups objects 'define', , have no references other entities; in ddd terminology, value objects. other examples of term lookup may team member's 'roletype', tester, developer, project manager example. person's 'title' define lookup - mr, miss, mrs, dr.
i model process aggregate as:
public class process { public processtype { get; } }
as say, these type of objects typically need populate dropdowns in ui , therefore need own data access mechanism. however, have not created 'repositories' such them, rather 'lookupservice'. me retains elegance of ddd keeping 'repositories' strictly aggregate roots.
here example of command handler on app server , how have implemented this:
team member aggregate:
public class teammember : person { public guid teammemberid { { return _teammemberid; } } public teammemberroletype roletype { { return _roletype; } } public ienumerable<availabilityperiod> availability { { return _availability.asreadonly(); } } }
command handler:
public void createteammember(createteammembercommand command) { teammemberroletype role = _lookupservice.getlookupitem<teammemberroletype>(command.roletypeid); teammember member = teammemberfactory.createteammember(command.teammemberid, role, command.dateofbirth, command.firstname, command.surname); using (iunitofwork unitofwork = unitofworkfactory.createunitofwork()) _teammemberrepository.save(member); }
the client can make use of lookupservice populate dropdown's etc:
ilookup<teammemberroletype> roles = _lookupservice.getlookup<teammemberroletype>();
Comments
Post a Comment