It would be easy for the team to conclude that they only needed to factor out the tight coupling to User and Permission. After all, there would not be anything wrong with separating User and Permission/Role into a separate Module. That could help them place these concepts in a separate logical Security Subdomain within the same Bounded Context. However, what made the best modeling choice stand out even more boldly was the realization that the team’s next Core Domain project would have very similar role-based access needs and would lean on the use of domain-specific role characteristics. Clearly, Users and Roles were truly part of a Supporting or Generic Subdomain that had an enterprise-wide, and even customer-facing, part to play in the ...
Share this highlighthttp://www.safaribooksonline.com/a/implementing-domain-driven-design/8180470/