That is the question I have been pondering these past few weeks. It led to a series of interesting conversations with Steve "ardalis" Smith on our devBetter community Discord server. At the time of these discussions I wasn't sure of the answer. I was however leaning towards the idea that most Single-Page Applications (SPA) were not Bounded Contexts (BC) but in fact belonged to the BC of their corresponding server-side API.

Steve had the good idea to consult the Twittersphere to see what other developers thought. The results were far from conclusive with only 54% of respondents being of the opinion that the SPA was part of its server-side API's Bounded Context. A majority, but barely.

I would need to analyze this question further to come to a satisfying conclusion. So I decided to go back to the source, to the authoritative works on the subject of Domain Driven Design (DDD), namely, the works of Eric Evans and Vaughn Vernon.

This analysis led me to the conclusion that the majority of SPAs (those backed by a corresponding, in-house, server-side API) are not BCs in their own right but, rather, belong to the BC of their server-side API. Here's why.

First, some definitions

Our question involves three elements: 1) a Single-Page Application 2) a server-side API 3) the concept of a Bounded Context. I thought it would be prudent to make sure I was really clear on what those three things were before trying to answer our question.

Single-Page application: A client-side web application that doesn't need to load new pages from the server. The kind of application you would generally write with Angular, React, Vue.js or Blazor frameworks.

Server-side API: A server-side application containing business logic and exposing an API to web clients, often through REST endpoints. You could write such an application with the ASP.Net or the Spring frameworks, to name but a few. These applications are usually backed by a database.

Bounded Context: .... and this is were we get in trouble. As I read through the DDD body of work, I quickly realized that the concept of a Bounded Context was not that easy to define. This is precisely why it seemed hard to find a clear cut answer to our question. So, before we can go any further, a discussion on what constitutes a Bounded Context is in order.

What is a Bounded Context

In Evans' blue book on DDD, in the glossary, we find the following definition for Bounded Context: "The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared understanding of what has to be consistent and what can develop independently." A little vague, I know.

Vernon, for his part, says in 'DDD Distilled'  that a "Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has specific meaning and does specific things. The components inside a Bounded Context are context specific and semantically motivated. That's simple enough. " No Vaughn, no, it's not simple enough. But thanks for trying.

To understand both of Evans' and Vernon's definitions, you kind of have to understand the concept of Ubiquitous Language(UL). Notice how Vernon talks about a "semantic contextual boundary" and about the components being "semantically motivated"? He's talking about the UL. In other words, according to Vernon, one BC equals one UL.

A Bounded Context is a part of the system where the same people work on the same things and call those things by the same names.

So what is a Ubiquitous Language? Evans says it is "a language structured around the domain model and used by all team members to connect all the activities of the team with the software." In other words, on the team, if I'm talking about a Product or a Customer, everyone knows exactly what I'm referring to. Now, another team working on the same app might also have to deal with Products or Customers but they have a slightly different definition of what they are and what they do. As such they do not speak our Ubiquitous Language and therefore are dealing with a different Bounded Context.

So, if I had to give my own, super simple, definition of a Bounded Context I would say that it is a part of the system where the same people work on the same things and call those things by the same names.

Yeah, I know, still a little vague. I wasn't very satisfied either. In this article we have defined, in the abstract, what a Bounded Context IS. Still on our quest to determine if a SPA is a Bounded Context, in the next article we will look at what a Bounded Context HAS. What is part of a Bounded Context? What does it contain? Keep reading to find out...