Domain-Driven Design: Is a Subdomain a class?

Question

Let's consider that we use OOP.

Is a Subdomain a class? And Bounded Context is a set of classes that are used together for the only purpose(ideally)? Can on subdomain contain a set of classes? If yes, then what is the difference between Bounded Context?

For example, we have a domain: Online shop.

We divide Online Shop in 2 subdomains: Customer Support and Shopping.

We see that such a division is still huge, so we divide:

1. Customer Support in Customer, Supporter, Ticker subdomains. Now such subdomains become classes, and the divided subdomain becomes a bounded context.
2. Shopping in Customer, Cart, Payment subdomains. Now such subdomains become classes, and the divided subdomain becomes a bounded context.

Probably it's not the best example of subdomains, but the point is to give you understanding of my problem.

Answer 1

I will try to explain, you are mixing things.

• Subdomain. It belongs to the problem space. Here you don't have classes or anything about a programming language. You have concepts, relationships, etc. When you have to solve a problem, you have the domain of that problem. If that problem is wide, you divide it into smaller subproblems, which are problems too. So a subdomain is the domain of a subproblem.
• Bounded Context (BC). It belongs to the solution space. Here you do have classes or whatever else artifacts of a programming language. If you have a problem, a BC is the application that implements and solves that problem. You model the domain of the problem, so that you have a domain model. Ideally the BCs relates 1:1 with subdomains.

Whether a BC is just a class or a lot of them it will depend on the granularity when you split the domains into subdomains, and how you model the subdomains. There isn't any rule about how many classes a BC should have.

Hope my explanation helps.

Answer 2

Recently I read Implementing Domain-Driven Design by Vaughn Vernon and I highly recommend you to read this great book. This is how I would define these concepts in few words, based on the book:

Domain - what organization does; a specialistic knowledge together with different actions. Domains are the problem where bounded contexts are their solutions.

Subdomain - a part of domain.

Bounded Context - clear boundary with specific ubiquitous language. Best when each subdomain has its own bounded context. Should be as big, as it is necessary to express its whole ubiquitous language.

But sure there is still a lot to say about it.

Answer 3

A subdomain would probably not be a class.

<shameless plug> Here is an excerpt from my book: </shameless plug>

Domain

The domain is the total area of focus for our model.  Irrespective of the size of the domain you are in all likelihood going to run into a situation where different parts of your domain model will belong together. As with most things we will divide and conquer.

Although the following divisions in the domain are given specific names based on how you view them it is largely academic. We shouldn't need to split hairs over this and if you start off grouping the domain into logical units and calling each a subdomain then that is absolutely fine for a start.

Core Domain

This is the main part of your domain and carries the most weight. In terms of stock market parlance this falls right in the headline earnings space. It is the raison d'être of your domain. This part has to work and has to work well and is that part of your system that everything revolves around. If you have a hard time nailing this down it means that you have a rather large core domain. It is what it is.

Generic Subdomain

These aid in performing certain tasks in a generic way and the implementation details are not that important to our core domain. Financial accounting and calculation engines could be bought off-the-self and be used to perform these functions.

Supporting Subdomain

I think there is often confusion between generic and supporting subdomains. A supporting subdomain isn't something that is generic enough that you would probably find anything off-the-shelf available. It would be quite specific to your business requirements but still does not fall into the core of the business.