In the first and second article in the series we have established that a Bounded Context includes more than just the domain model but extends to the other layers of our system, in a vertical slice.

To better understand how this all plays out, and why this means that a Single-Page Application should be part of it's server-side API, I decided to map out a simple class diagram over Uncle Bob's famous clean architecture. First, for comparison, I mapped out the typical MVC application.

If you are not familiar with this architecture or diagram you'll find plenty of examples with a quick Google search for "Clean Architecture". Suffice to say that at the center, in yellow, is the domain model. This diagram is meant to represent one specific use case, a vertical slice, dealing with Products. According to Vernon, this entire diagram could constitute a Bounded Context.

Now let's look at what the same use case would look like with a SPA.

There is a bit more going on here, as can be expected. But as you can see, the core of our application didn't change. We are still using the same domain model, application service and repository interface. The only thing that changed is that we have added a few intermediaries between our ProductController and our View. That's normal since we now have to go through the Web to reach it. The important thing here is to realize that the fact that we have swapped our client from a traditional server side MVC UI to a SPA didn't change anything for the core domain. And everything in this diagram is is still a vertical slice, handling the same use-case, dealing with Products.

So, if the setup in the first diagram is a Bounded Context it stands to reason that the setup in the second diagram also represents one Bounded Context. We haven't changed the domain model. We haven't changed the words we use to refer to the components in the domain model. We are still talking the same Ubiquitous Language.

As stated previously, the components in the green and blue layers are not part of the domain model, but they ARE part of the Bounded Context. If we swap components in and out of the green and blue layers but don't add anything to the pink and yellow ones, we're still dealing with the same domain model, the same Ubiquitous Language... the same Bounded Context.

Does it even matter?

When I was discussing this with Steve - remember him from the first article? - he rightfully reminded me that "all models are wrong, but some are useful". So the question is, despite the fact that, according to our analysis of the DDD literature, viewing the SPA as part of the same BC as the server-side API is more "right" than viewing it as a separate BC, is it more useful?

All models are wrong, but some are useful

I honestly don't know for sure, but I do see some advantages to modelling it that way. One of them stems from what Vernon says about Bounded Contexts and teams. He says: "There should be one team assigned to work on one Bounded Context. [...] It is especially important to be clear that one team works on a single Bounded Context."

I do believe that the best way to develop software is generally to work in small, multidisciplinary teams, using vertical slices. Given what Vernon says, if we were to model the SPA as it's own BC, we would presumably have different teams working on the SPA and the back-end, which I think is less than ideal. But that's a topic for another blog post.

What do you think? Is it more useful to view the SPA as its own BC, or as part of the server-side API's BC? Why? Let me know in the comments.