2

I am working on handling authorization for an application. I need some way for a command handler to ask the Authorization bounded context "Is this user allowed to perform this action?".

User account creation, deletions, locks, etc. as well as permission and roll management will generate the appropriate events.

The best option I can think of at the moment is to have a service class that exposes a CanUserExecuteCommand(Guid userId, Command command) method that command handlers can call as needed. This service would listen for account/permission events and any other relevant domain events to track which user can do what.

To me, this looks like a query (no side effects, event stream projections), however, deciding what a user can or can't do sounds like business logic to me.

Is it appropriate to have this kind of logic on the query side? And where should this service live, along side the domain model, or in the read side? Is there a better way to design something like this?

Improve this question
2
  • Well the command handler asking the Authorization bounded context "Is this user allowed to perform this action" is a query. What the command handler does with that information is up to the command handler.
    – Robert Harvey
    Apr 3, 2019 at 20:48
  • The Command side can do "queries" to the Query side as well as soon as it uses the proper IPC and doesn't access to the data directly bypassing the "Bounded Context" that owns the information.
    – Laiv
    Sep 2, 2019 at 10:38

1 Answer 1

Reset to default
1

If you are not in the Identity and Access Management context, "Is this user allowed to perform this action?" should not be a part of your business.

The role of deciding whether the user can do something (i.e. authorisation) should belong to the application layer instead of domain layer. Your application should check the permission of the current user from the IAM context before sending the query request to your domain services. The response from the IAM context is not just a "yes" or "no". It should be a value object that describe the role of the requested user.

The best option I can think of at the moment is to have a service class that exposes a CanUserExecuteCommand(Guid userId, Command command) method that command handlers can call as needed. This service would listen for account/permission events and any other relevant domain events to track which user can do what.

If you implement such a method, the method should belong to an application service, not a domain service. Personally, I will ask the IAM service instead of maintaining a local copy of authorisation data.

Improve this answer
1
  • This answer doesn't really address the main question in my post, "Is it appropriate to have this kind of logic on the query side?". Otherwise, I think most of my approach is inline with what you said. This method would live within the Authorization/IAM context. Other contexts will not be maintaining their own copies of auth data. It would be called by the command handlers, which are in the application layer. Command handlers load/create the appropriate domain object, call the appropriate method on the domain object, and then persist the results; they don't contain any domain logic themselves.
    – Entith
    Apr 4, 2019 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.