In domain-driven design (DDD), a subdomain is a smaller, specific area of a larger domain that has its own unique characteristics and requirements. Subdomains are used to group and organize related concepts within a domain, and to provide a more focused and detailed level of understanding of specific areas of the domain.

For example, consider a large e-commerce domain. Within this domain, there could be several subdomains such as:

• The inventory management subdomain, which deals with the management of products, stock levels, and reordering.
• The customer management subdomain, which deals with the management of customer accounts, orders, and returns.
• The shipping and logistics subdomain, which deals with the management of deliveries and shipping.

Each subdomain may have its own set of entities, value objects, aggregate, domain services and domain events that are specific to that subdomain, but also may share some concepts with other subdomains.

Using subdomains can help to create a more modular and maintainable domain model, by breaking the large domain into smaller and more manageable parts. It also can help to improve the communication and collaboration between developers, stakeholders and domain experts, by providing a more focused and detailed level of understanding of specific areas of the domain.

When designing a subdomain, it’s important to identify the relevant concepts and relationships, and to model them in a way that is consistent with the overall domain model. It’s also important to define the boundaries of the subdomain and to ensure that they are clearly communicated to the other subdomains and the overall domain.

Relation to domains

Subdomains are related to domains by organizing the domain into smaller, more manageable parts. By breaking down a larger domain into subdomains, each subdomain can be understood and modeled more easily, and can be developed and maintained by a dedicated team of developers.

Subdomains may have different bounded contexts, which are areas of the domain where a particular model, language, and rules apply. These bounded contexts help to keep each subdomain separate and isolated from other subdomains, allowing for more flexibility in development and easier maintenance over time.

Overall, by organizing the domain into smaller subdomains with their own specific language and rules, DDD allows developers to create more maintainable, scalable, and extensible software systems that better reflect the business domain.

Example

Consider an organization that operates in the banking domain. Some of the subdomains for this organization may be depicted as follows:

Subdomains themselves may turn out to be extremely complex. And this might require us to further decompose them to manage the associated complexity. For example, the Acquisitions subdomain may be further composed of:

This decomposition can continue until we get to a point where we feel we have a grasp on the complexity and deal with it effectively.

Types of subdomains

There are three types of subdomains:

1. Core subdomains: These are critical to the organization’s business and are often the main focus of development efforts. They provide a competitive advantage and are unique to the business.
2. Supporting subdomains: These subdomains are necessary for the core subdomains to function effectively. They may be non-competitive and are often shared across different systems.
3. Generic subdomains: These are common to many organizations and are not specific to any particular business. They provide a common infrastructure and are often outsourced or purchased as off-the-shelf software.