Timeline for How to implement authorization that needs to be done in the same transaction as aggregate method runs in (DDD)?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 18, 2021 at 15:39 | comment | added | Rik D | From my viewpoint, your option 3 is leaking domain knowledge. But if you don't consider these rules business rules then by all means do what works for you. The thing with DDD is that it requires a lot of domain knowledge and refining of the model when your knowledge increases. Don't be affraid to try something out and change if it doesn't work. | |
| Feb 18, 2021 at 15:01 | comment | added | user606521 | But does anyone do this in real world? It feels wrong to have let's say half of authorization defined in authorization/controller layer and half passed from authorization/controller layer, through application/command layer, into domain layer. Feels that code will be messy - maybe it's better to break some rules here to keep authorization in one place? Are there any cons of my example #3? The only I see is that authorization layer has access to repository and aggregate object but it can be implemented in the way that it has readonly access to aggregate object. | |
| Feb 18, 2021 at 10:29 | comment | added | Rik D | I agree that general role-based authorization is usually not a domain concern. But as you noticed yourself, this scenario is different, it's conditional. You still have authorization outside of the domain, but this additional validation should be done in the domain imo. | |
| Feb 18, 2021 at 10:00 | comment | added | user606521 | I mean very often in the system it's relatively "easy" to define domain logic from business requirements but actual authorization rules might not be well defined in the beginning and may change quite quickly I think? I feel like it would be easier to handle authorization on different layer from domain... | |
| Feb 18, 2021 at 9:56 | comment | added | user606521 | Hmm I know this pattern, its kind of "domain service" right (additional business logic passed to aggregate method)? Are you sure this kind of logic should be handled in domain level? I mean this is "authorization" part which I think should not be implemented in domain logic (according to all sources I read) because it's does not even have impact on domain model consistency (in opposite to some relation between two aggregates for example). Also authorization may change over time (more checks, more rules, different user types etc) and it would be easier to not change domain model in such case? | |
| Feb 18, 2021 at 9:29 | history | answered | Rik D | CC BY-SA 4.0 |