Subdomain

A Subdomain in DDD is a distinct group of concepts in the Business Domain. These concepts work in tandem with each other and often reference each other in business workflows.

When concepts from all over the software landscape are added to a domain model, the language of the model becomes blurred, resulting in confusing terminology. This confusion ultimately makes its way into software code, resulting in a Big Ball of Mud, with unrelated concepts spread across multiple modules, interconnected with conflicting concepts, and maintained by multiple teams.

Subdomains reduce complexity by grouping related concepts and isolating such groups of concepts into different Bounded Contexts, each having its own Ubiquitous Language and Software Implementation.

A Subdomain can have both tightly connected concepts (like Savings Account and Interest) as well as independent elements (like Savings Account and Credit Card). A common language (also known as Ubiquitous Language) is what usually decides the boundaries of a Subdomain. Within the Subdomain, a business term has a very specific, unambiguous, stable meaning.

An ideal modeling composition would be one Subdomain per Bounded Context, and one Bounded Context per Subdomain. Other combinations are not optimal.

Subdomains isolate problem spaces and facilitate discussions about areas of the business that one doesn't have control over but still need to deal as part of the Core business. These could be legacy systems, areas where the company has no expertise or capability, or domains that are too volatile and not well understood.

Monolithic applications typically have multiple Subdomains collapsed together into a single Bounded Context, creating a Big Ball of Mud. Thinking in the form of Subdomains helps limit the complexity of the problem space. By isolating Subdomains, we can identify the basic Ubiquitous Language terms and distinguish between valuable Subdomains versus those that are just playing a support role.