In Vaugh Vernon's book "Implementing Domain Driven Design", the team separated the Identity and Access from Collaboration context because the team realized they are being stuck on the "role-based" mindset and what they needed was simply just Author, Moderator, Creator, etc and those can be fetched from Identity And Access context which contains infos like roles, credentials, and Person info which then will be translated by a Translator into the right "role" (Author, Moderator, Creator, etc.)

So my problem is different, I will be having no roles at all (or maybe I am not just seeing it yet. HR currently doesn't have an account in this iteration).

Scenario: HR will activate Employee's account -> employee will receive a default pass by Sms which he can change later on.

So now my question is: do I need separate BC for the employee's account? Or should I just add a password property in Employee AR?

  • 1
    The purpose of DDD is to create systems that are easy to change. Following DDD means that as new requirements manifest your design is supple enough to be refactored accordingly and without much pain (usually). Let the behavior (as it looks right now) inform the design of your system. Do not allow the possibility of future changes prevent you from delivering your system now! – king-side-slide Dec 18 '18 at 16:36
  • Upvoting for pragmatic comment. I actually had a separate BC temporarily so I can deliver now, but still waiting for a formal correct answer. – doesnotmatter Dec 19 '18 at 19:54

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.