Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

5
  • 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? Commented Feb 18, 2021 at 9:56
  • 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... Commented Feb 18, 2021 at 10:00
  • 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. Commented Feb 18, 2021 at 10:29
  • 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. Commented Feb 18, 2021 at 15:01
  • 1
    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. Commented Feb 18, 2021 at 15:39