1

We are currently in the early phases of developing several applications that differ significantly in their functionality. As part of building these applications, we have also developed a few generic BCs. Ideally these BCs should be reusable in order to minimize duplication and remove cross cutting conerns, and further improve development of future applications. Among these are a generic BC used to handle notifications such as emails, a BC dedicated to activity feeds, and more--and even more in the future.

This all works well and nicely in terms of the functionality they implement. However, I am unsure as to how to handle authorization and filtering of data in the case of either querying or executing commands.

Essentially, the source of truth with respect to the authorization rules are the non-generic applications/BCs. These applications can be totally different, but they all require authorization and the use of zero or more of the aforementioned generic BCs. Now, comes the question: What is the best way to handle this cross cutting concern without having to duplicate authorization logic for each new application we develop?

Our plan was originally to have a generic BC for Security that stores information about the resources and subjects that are in the system. In order to enforce the authorization, we envisioned developing an API-gateway for each non-generic application we develop and have the API-gateway enforce security policies. This approach should work well for handling authorization of command.

However, for queries, things seem to be complicated. For instance, our activity feeds may contain records that only a subset of the users of some application should be able to see, based on their roles in that specific application. In addition, some users may be able to only access a subset of the information of the returned records. For instance when fetching information from the generic BC that handles a Filesystem, some documents should be visible to some, while hidden from others.

Would filtering the information provided by the generic BC in the API-gateway before returning the data be a viable solutions? For instance when a given user fetches an activity feed from the Activity BC, the API-gateway queries the Security BC for information required to filter the results. This would incur overhead by having unnecessary data returned from the generic BC (i.e. the records/fields that are removed after filtering), but on the other hand this greatly reduces the complexity that filtering within that BC itself would incur. To me it seems that there should be a better approach without polluting each and every generic BC with authorization logic.

I have also read about the sidecar pattern. Would it make sense that each service implementing a generic BC has a sidecar containing the generic Security/Authorization BC? In order to avoid polluting each QueryHandler with authorisation filtering, the query result could e.g. be passed through a filter that interacts with the sidecar.

I am sorry for the long post; I hope I articulated myself in an understandable way. The approach to solving cross cutting concerns in DDD (and microservices) seem to be a highly debated topic, and it can be overwhelming to interpret the massive amounts of opinions regarding this.

3
  • What does your chosen architecture have to say about this? (DDD is not an architecture; you're almost certainly using something else). Commented Jun 24, 2021 at 13:58
  • Thank you for the reply! Our architecture is a distributed, SOA. For some of the subdomains, we use DDD principals to design the system and discover boundaries. The problem mostly arises with respect to authorization in the generic BCs. That is, whether they should contain their own authorization logic. Ideally we want to be able to reuse these generic BCs for new applications and other parts of the system.
    – udnes99
    Commented Jun 24, 2021 at 14:32
  • Sounds like the authorization needs to live in the BC's. Commented Jun 24, 2021 at 14:42

0

Your Answer

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