What actually is a subdomain in domain-driven design?

Question

So I was reading the book "Implementing domain-driven design by Vaugh Vernon" and there's something that I don't understand. To make it clear, Let's look at the picture that I took from the book. Here's how he describes DDD concepts such as bounded context, subdomain and etc.

So as you can see in the picture, it describes the domain of a retail company. You have implicit bounded context and also a subdomain inside of a bounded context, but after reading a few pages further I found this picture.

So now it makes me confuse because in the first picture subdomain is living inside of a bounded context, but in the second picture bounded context is living inside of a subdomain (Core, Support, Generic) instead. So what is actually a subdomain that he describes in the first picture. Are they the same thing as the second picture?

Answer 1

You don't have subdomains inside bounded contexts. It is more like this:

The domain represents the problem space and bounded contexts represent the solution space. In Software terms that would relate to an implementation of a solution for a specific problem.

Each company has an overall domain which usually consists of different sub-domains if the domain has a certain complexity (the reason for choosing DDD after all).

It is important to note that these sub-domains can be categorized into:

• core sub-domains, those where the company money makes with their competitive edge)
• supportive sub-domains, things that do not really add value for the end customer but are needed to realize the workings of the core sub-domains, also they represent rather custom problems of the company which cannot be fulfilled with ready implementations on the market and
• generic sub-domains, problems that are very common to several companies

For instance, a flower online shop would have the super fast delivery of flowers at the same day as it's core sub-domain. Then, for instance, their purchasing could be a supportive sub-domain - not relevant to the end customer but complex and custom enough that the problems of that sub-domain are not similar to other companies. And how they secure their website authorization for customers (e.g. using OpenID Connect / OAuth2) would be a generic sub-domain for which they would rather use a ready solution and they would not implement their own identity provider.

The respective bounded contexts are just the corresponding solutions to those problems (sub-domains). Although there can be a 1:1 mapping between sub-domains and bounded contexts that does not have to be. While sub-domains are discovered bounded contexts are designed and modelled to provide the best solution to the problem space and to define the respective boundaries that make sense in your system.

As developers we cannot choose which sub-domains there are, that's a given. But we can, with respect to the context and constraints of the situation, choose how we cut boundaries, for instance, to have physical separation or also team development responsibility separation. Either way we need to know that a bounded context defines language boundaries and we have to make sure that there is no conflict in the language inside that bounded context.

Update:

I want to answer to the additional question (see comment):

can a bounded context live in more than 1 subdomain. As you can see in the second picture, the bounded context inside of generic subdomain seems to overlap with other subdomain.

I recommend having a look at figure 2.4 and respective text in the book, in chaper 2, REAL-WORLD DOMAINS AND SUBDOMAINS.

In this case the generic sub-domain is ERP (enterprise resource planning). It's a good example for something that is available as software from third party providers and can be integrated into your system.

The respective bounded context ERP is overlapping the inventory and purchasing sub-domains as this implementation also provides inventory and purchasing ERP modules (or APIs) that allow those sub-domains to consume the ERP context.

So although these specific modules (or APIs) address the needs of the supportive sub-domains inventory and purchasing they are implemented in the ERP bounded context rather then the inventory and purchasing bounded contexts.

So yes, although a 1:1 mapping between sub-domains and bounded contexts would be desirable, when it comes to the implementation it can sometimes be necessary that one bounded context deals with requirements from more than one sub-domain. Also, in legacy systems there are often constraints that don't allow you to freely create the optimal design of bounded contexts.