"User" is not a Bounded Context—and yet, the user matters
“User” is not a Bounded Context—that’s the first misconception to correct in DDD training. It’s too vague, too tempting to lump everything into it. And yet: no architecture can afford to ignore its users. Modularization must be reconciled with the user experience. Here’s a pattern that attempts to address this tension.
A context for presenting personas
Let’s start with the problem: modularization is great, but as they point out Mathias Verraes and Rebecca Wirfs-Brock point out, it’s an approach that belongs in the realm of solutions. In other words, your users don’t care about it. Nor do they care about your user stories, if you really think about it. For them, the only thing that matters is a useful and easy-to-use application.
This assumes that the user has a single interface that allows them to do everything and switch seamlessly from one context to another. If I buy a product and want the corresponding invoice, it would be absurd to have to log in to a dedicated invoicing app, because it would interrupt the workflow. However, in terms of APIs, there will certainly be a dedicated invoicing API.
This clearly illustrates the need for a context designed to present information to each user profile, to each persona. It presents information drawn from the core contexts and has its own language. For example, the language of a front office will generally be simplified, understandable to as many people as possible, while that of the back office will remain specialized, spoken by business experts. The information architecture will likely also be very different between these two contexts.
It’s easy to imagine what this might look like in a service we’re all familiar with, Doctolib: we can already picture the “Healthcare Professional” and “Patient” contexts, serving as single entry points to other contexts such as “Schedule an Appointment,” “Online Consultation,” and so on.
To each context, its own BFF
BFF… as in Best Friend Forever? Not really.
In the case of a Single Page Application (SPA), calling multiple APIs from the browser isn’t ideal—primarily for security reasons. So we decide to provide the front end with a dedicated API, to which we delegate this task. This is called a Backend For Frontend (BFF). As is often the case, the name says it all, but let’s take a closer look at what it means:
-
A BFF provides the SPA with a single entry point for screen-oriented requests. Example: “Give me my order history, with a link to the corresponding invoice for each order, if one exists.” Information from two contexts—and therefore two APIs—is compiled into a single response.
-
A BFF enables shared authentication: in an OAuth2 flow, the BFF validates the JWT token and forwards it to the services it interacts with (token forwarding) or requests that the identity provider issue a technical “on-behalf-of” token (token exchange/delegation).
A BFF is therefore essentially a proxy: it facilitates read and write interactions with other contexts, which know nothing about the user (they only know the user’s role, carried by the token). The combination of the SPA and the BFF constitutes the user context, and there are as many of these as there are personas.
A presentation context dedicated to a category of users is a way to take the user into account, whereas a modularization approach might tend to overlook them. A presentation context is therefore not a “user” context. While the former is a valid pattern in DDD, the latter—synonymous with large-scale coupling—remains an absolute anti-pattern.