I see that Kenny wrote almost exactly the same as I did in the previous comment. The domain is also known as the subject matter. Since you cited the DDD Reference, I will do it too :)

Domain: a sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of software.

As we don’t write software just for the sake of writing software, we are always attempting to solve a particular problem in hand. The problem is something that we have to deal with in real life, something we want to automate, improve, or even make possible to do. Without a problem, writing any software is pointless. Even purely technical bits of software like hardware drivers, operating systems, databases and frameworks — all aim to solve some problem, which comes from the problem space.

We talk to domain (subject matter) experts in order to understand the problem better and write better software. A deep dive to the problem space gives us an understanding of the domain. With that knowledge, we then are able to apply our modelling skills to design a model. Models don’t aim to catch every detail of reality but aim to give us a tool for solving the problem. Getting back to the Reference:

Model: a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

By designing the model, we contextualise it and focusing on problem-solving. Right there, we are moving to the solution space, as the model is a part of the solution.

As Kenny mentioned in the GitHub discussion, a bank would be an enterprise operating in the domain of finance. But, such a domain is hard to comprehend, so by observing the structure of the bank, we can find smaller (sub)domains inside the enterprise. Since most of the industries existed before computers, all the knowledge about structuring a particular business is already there. Contexts, however, aren’t very obvious for an outsider as people who are inside the context often don’t even realise the difference of meaning for the terms they use, compared with other parts of the organisation. An outsider might assume that the bank accounts for private and corporate customers are the same things. However, if you have both private and corporate account in the same bank, you can clearly see the difference even in the UI. We can find some context boundaries already by looking at subdomains, and by digging deeper, we find less obvious (again, for us) subtle differences between different account types available for a certain type of customers. For example, a tax deduction account is only available for corporate customers, and such an account has lots of very specific rules, which have zero applicability for the normal account.

Let’s now have a closer look at contexts. There’s a lot of confusion about these terms, which I also experienced myself some time ago.

The definition of context is quite clear, and it’s purely linguistic. We ask for the context in any discussion as we need to align our thought process to the terminology used within the context. Hence context switching is a frequently used phrase with a lot of negative connotation as our brain doesn’t like switching contexts since it requires quite a lot of energy. Contexts are always domain-specific and live in the problem space. A context has nothing to do with software as it exists regardless, it is, again, a part of reality.

Bounded context, however, is a thing of the solution space. It is software. The boundary of a bounded context is always a boundary of some system. If for all my complex domain with several subdomains and a few linguistic contexts, I only have a poorly-structured monolithic system (Big Ball of Mud), I have a single bounded context. I used to draw a “context map” of a monolith, trying to make sense of things, but that exercise is pointless. Such a context map would have one huge shape in the middle, which is my monolithic system, and the only way out of it is to start creating something like bubble contexts, sucking parts of the existing system functionality to the outside. The more bubbles I manage to create, the better my context map becomes, the smaller is the size of the legacy monolithic system.

Finally, I have to mention that I don’t fully understand the statement that we change the problem space by writing software. We might if we are creating a new problem space. For example, there was no problem space for mobile app stores until smartphones became a thing, and we got tons of apps needing a place for distribution. But it is the area of a high level of novelty, an unexplored territory. Most of us deal with well-known problems in established industries; some of those are hundreds of years old. We don’t change anything there. We can make things better, faster, easier to use, easier to understand, but that’s all. All those attempts are solutions for known problems, which we aren’t capable of changing.