What are subdomains, really?

Question

In studying domain-driven design (DDD), I've come across the concept of subdomain, but I think I don't get it yet. My first understanding of this was that a subdomain is a subset of the domain of the application. In other words, it's a partition of the problem space. I've read that there are three types of subdomain:

• core subdomains
• supporting subdomains
• generic subdomains.

My understanding was somewhat like this: We pick the domain of the application, and it is quite complex. Then we look at it and we figure out a way to partition it into simpler pieces, some of which would be core subdomains and some of which would be supporting, while others would be generic.

In searching for more information, I've found some people saying something different: That just one core subdomain exists, along with some generic subdomains and no supporting subdomain whatsoever.

So my questions are:

1. What are subdomains, really? Is my first understanding the correct one, or is it the second thing I read?
2. How is this idea of subdomains useful?
3. What are some good criteria for identifying subdomains? What should we have in mind when deciding on subdomains in order to make better use of this idea?

EDIT: Searching a little more, I found the following:

Think of an e-Commerce system. Initially you can tell that it is an application of a shopping context. If you look more closely, you will see there are other contexts too, such as Inventory, Delivery, Accounts, etc.

This is what I initially thought a subdomain was. We pick a domain (the shopping domain) and break it down into simpler subdomains (inventory, delivery, accounts, and so on). But in the text in question, they refer to these as contexts. So is my former understanding not subdomains but contexts?

I've found one question here on this site about the difference between a subdomain and a bounded context. The answer states that subdomains are a partition of the problem space, while contexts are partitions of the solution space. Yet, separating the shopping context into inventory, delivery, accounts, etc, is not a conceptual partition. That is, is it in the problem space rather than the solution space?

Answer 1

Disclaimer: I'm not a DDD expert, but I'm going to do my best here to answer your questions.

Let's use an Online Book Retailer as an example. A book seller is offering to sell books on his website, but he doesn't print the books himself. Instead, he has a long list of "Book Suppliers" who print and ship the books to his warehouse, were he packages them and ships them to the customers all around the world.

Could you imagine the teams working in that company?

1. The listing team: The team that selects which books they should list on the Website, depending on the stock of the suppliers.
2. The fulfillment team: responsible for collecting the orders from the Website and managing the orders' life cycle.
3. The commercial team: these are the guys who handle adding or removing suppliers from the system.
4. The marketing team: responsible for the campaigns and offers.
5. The warehouse team: responsible for collecting books from the suppliers and shipping them.

Each team will use its own terms to describe what it is doing. Teams will use the domain language or the "Ubiquitous Language", as Eric Evans calls it. Normally, each team will have a different mental model of what an entity is. For example:

Listing team: BOOK(book_id, ISBN, title, price, weight, length, width )  
Fulfillment team: BOOK(book_id, totalPrice, sold_quantity)   
Shipping team: ITEM(book_id, delivery_date) --> they refer to the book entity as "item" 

A sub-domain is one particular part of the domain, in which some users use a certain Ubiquitous Language. When the language changes, this is an indication the you are crossing into another sub-domain.

What if two teams use the same terms? Both the fulfillment and listing teams call book "book". You will have to ask them, "what is a book for you? What are its key attributes? How is it used?"

Answers to these question will result in two different or similar domain models. The greater the difference between the two models, the more indication that these are two different Bounded Contexts/sub-domains. The opposite is also true. The more similar the two models are, the more likely that they should be part of the same sub-domain.

This may result in very interesting findings in your model. You may discover that inside the fulfillment sub-domain, the orders pass through different states (new -> requested -> shipped). Maybe each of these states requires complex management and different attributes, so you may divide this sub-domain into several other sub-domains.

This brings out a question of what the size of the sub-domain(s) should be. The answer is "let the domain model decide that". Whenever you see a change in the UL and model, then draw a boundary for that sub-domain.

Remember that DDD is all about the business, the people and the communication(s) between them. Let that drive your model.