domain driven design - Bounded Contexts and Aggregate Roots -

we trying model rbac-based user maintenance system using ddd principles. have identified following entities:

authorization aggregate root following:     user   (an entity object)     list<authority>    (list of value objects)  authority contains following value objects:     authoritytype (base class of classes role , permission)     effectivedate  role contains list<permission> permission has code , description attributes 

in typical scenario, authorization aggregate root since in user maintenance revolves around (e.g. can grant user 1 or more authority-ies either role or permission)

my question : role , permission? aggregate roots in own separate contexts? (i.e. have 3 contexts, authorization, role, permission). while can combine in 1 context, wouldn't role heavy enough since loaded part of authorization "object graph"?

firstly can't feel you've misunderstood concept of bounded context. you've described bc's describe entities. in mind, bounded contexts serve give entities defined in ubiquitous language different purpose given context.

for example, in hospital domain, patient being treated in outpatients department might have list of referrals, , methods such bookappointment(). patient being treated inpatient however, have ward property , methods such transfertotheatre(). given this, there 2 bounded contexts patients exist in: outpatients & inpatients. in insurance domain, sales team put policy has degree of risk associated , therefore cost. if reaches claims department, information meaningless them. need verify whether policy valid claim. there 2 contexts here: sales & claims

secondly, using rbac example while experiment implementing ddd? reason ask because ddd designed solve complex business problems - i.e. calculations required (such risk of policy). in mind rbac simple infrastructure service doesn't concern actual domain logic , therefore doesn't warrant strict ddd implementation. ddd expensive invest in, , shouldn't adopt sake of it; why bounded contexts important - model context ddd if it's justifiable.

anyway, @ risk of answer sounding 'academic' i'll try answer question assuming still want model ddd:

to me, fit under 1 context (called 'security' or something)

as general rule of thumb, make aggregate requires independent transaction, so:

1. on assumption system allows authorities added authorization object, make authorization aggregate. (although there might argument ditching authorization , making user aggregate root list of authorities)
2. authorities serve no meaning outside of authorization aggregate , created when adding one, these remain entities.
3. on assumption system allows permissions added role, role becomes aggregate root.
4. on assumption permissions cannot created/delete - i.e. defined system itself, these simple value objects.

whilst on subject of aggregate design, cannot recommend these articles enough.