What are subdomains in DDD
When you separates the domain between what is the motivation for the application and what is, so to speak, auxiliary, you have the core Domain and the Generic subdomains; the latter being the subdomains. (In DDD there is no artifact "supporting Domain").
Core Domain and Generic subdomains
You may have heard of core business.
Every company does a lot of important things, but not everything that matters is part of core business of the company.
The core business is the basic and central idea of a company. A simple example: in a car factory, although the arrangement of finished cars in the yard is important for business because of the impacts caused in logistics, the task of disposing the cars in the yard is not part of the core business of the company. The factory can outsource the disposal of the cars to a logistics company but will not outsource the own manufacture of the cars.
This analogy can be used to understand the core Domain:
CORE DOMAIN is the motivation of the software project or solution.
It is important to clearly identify and separate the core Domain because it is he who most adds value, so must have priority in investments - for example: must rely on the team’s main developers, their needs Refactoring has priority to others, hardly its functions will be exercised by third party frameworks.
And what is not part of core Domain will then constitute the Generic subdomains.
GENERIC SUBDOMAINS cover other business rules or models that are not part of the core Domain.
The parts of the model that add complexity but do not help to express the core Domain end up contributing to hinder their understanding, diverting the focus of what is most important.
An example of what stems from the lack of explicit separation between core and Generic subdomains is the project to have the best team developers focused on making generic high-tech frameworks (but not the lifeblood of the project) or modeling less important parts of the system as basic entries, while still unprepared professionals write the essential business rule with a "design" that can bring serious risks to the success of the project.
Note that we are restricted to business rules. In a system that persists data from core Domain in a relational database, data persistence is fundamental, but is not core Domain nor Generic subdomain, because she is part of infrastructure and not of Domain.
How to identify subdomains in DDD
It is no trivial task. If you are not careful, all relevant business rules will integrate the core Domain and the Generic subdomains will only have rules that should not have been implemented (such as a useless workbench).
Which will help identify the core is the definition that he is small. Another definition is that the core Domain is what more customer value delivery of the project, then the identification can be by comparison.
But the real key is the definition of Domain View. The Vision describes the motivation of the software project or solution and it is really very small, it fits on a page. So if a subject is not directly referenced by the Vision, it does not belong to the core Domain.
In order not to run the risk of making domain separations that may be more complicated than helping, do not make this division without due knowledge of the cause, that is, do not try to predict it. The knowledge of the domain is deepened during the project, so the notion of what is core and of what is Generic will also evolve throughout the project; and the separation happens not only once, but throughout the life cycle of the system through the refactoring of the models.
Completion
In DDD there is the core Domain and the Generic subdomains, whereas the core comprises the main reason for the application, which can be obtained from Domain View, and the Generic models that support the core.
The importance of separating them is, among others, to decrease the complexity of the core Domain and help prioritize investments (who does what, what should be done first, what can be outsourced...).
Thanks @Caffé, I was looking at Vaughn Vernon’s book and there he gives an example of a sales system. It divides the domain into "Product Catalog", "Orders", "Billing", "Shipping" and "Stock" subdomains. So the idea is to divide the domain into simpler parts and between them identify what is the main business, which would be the core? And then enhance what we understand as core refactoring over time?
– SomeDeveloper
@Leonardo I have not read this book so I do not know the idea of it. Just reading this your short example, I can also say that this are models of a domain and not subdomains, that are different things. A domain can have several models according to the concept of bounded context. And a domain can also be divided into core Domain and Generic subdomains, whereas the core may have several models and each Generic may also have several models. If these are models, I can say that "Orders" and "Collection" are the core Domain and that the others will integrate 1 or more Generic subdomains.
– Caffé