CODEWITHSUNDEEP
c#domain-driven-designsubdomainbounded-contexts
roro2012
roro2012

Reputation: 135

DDD:- How to organize Identity Access features in a solution?

Shall i put my identity access (Authentication and Authorization) in the shared kernel or create a separate bounded context called for example:- IdentityAccess

  1. If i put my identity access in the shared kernel, then the shared kernel will be bloated. the shared kernel should contain basic contracts such as BaseEntity or BasicValueObject to ease the development process
  2. If i choose to make the identity accesss in a different bounded context, then how the other bounded contexts will apply permissions

keep in mind, the identity access will contain a lot of features like User Login and Permission Management like(Create Users, rules and Groups)

Upvotes: 4

Views: 2059

Answers (1)

zaitsman
zaitsman

Reputation: 9509

Identity access should NOT contain Permission management; those are business functions belonging in the separate context, see this pic from Martin Fowler: enter image description here

Instead of Customer and Product in your case it will be Permission/Role/User etc. that exist in both bounded contexts.

So you should have:

  1. Context for authentication/authorization
  2. Context for permission management
  3. Business contexts.

Then you need to organise the code in such a way that user interaction always goes through (1) but in a way that is opaque to (2) and any number of (3).

Specifically, you should NOT worry about permissions in the business context because it should never be invokable if the user does not have appropriate permissions.

Upvotes: 2

Related Questions