Introduction

Domain-driven design (DDD) is an approach to software development that has gained a lot of attention in recent years. It is an approach that puts the focus on the domain or problem space, rather than the technical details of the solution. Within DDD, there are several key concepts that are important to understand, including domains, subdomains, and bounded contexts. These concepts can be confusing, and it can be difficult to understand how they relate to each other. In this article, we will explore the differences between domains, subdomains, and bounded contexts, and how they fit into the overall picture of DDD. We will also discuss how understanding these concepts can help you build better software systems that are more aligned with the needs of your business or organization.

Domains and subdomains

A domain refers to a sphere of knowledge or activity in the real world that is relevant to the software being developed. It is a specific area of expertise that has its own language, concepts, rules, and practices. A subdomain, on the other hand, is a smaller area of knowledge or activity within a larger domain. It can be thought of as a distinct aspect or sub-area of the larger domain, with its own unique language, concepts, and models.

Example

Let’s consider an example e-commerce platform. The subdomain of “Order Management” can be further decomposed into smaller subdomains such as “Shopping Cart Management”, “Payment Processing”, “Shipping and Logistics”, and “Order Fulfillment”, etc.

Each of these subdomains can be further decomposed as needed. For instance, “Payment Processing” can be further decomposed into subdomains such as “Credit Card Processing” and “Payment Gateway Integration”.

The level of decomposition depends on the complexity of the business domain and the specific requirements of the software being developed.

Why does this matter?

The decomposition of domains and subdomains is necessary to manage the complexity of large software systems. By breaking down a large domain into smaller subdomains, the team can better understand the business requirements and the software’s behavior. This leads to a more manageable and maintainable codebase. Additionally, subdomains can be developed and updated independently, which allows for greater agility and flexibility in responding to changing business needs. Finally, subdomains can be assigned to different teams, which allows for parallel development and better collaboration between team members.

Bounded contexts

Bounded contexts are related to domains and subdomains in the sense that they provide a way to further break down a large and complex domain into smaller, more manageable pieces when conceiving a solution for the problem. A bounded context is a specific area within a domain where a specific set of concepts, terms, and rules apply, and where a specific language is used to communicate.

Example

Now, let’s take the subdomain of order fulfillment as an example. Within order fulfillment, there could be several bounded contexts, such as the shipping system, the returns system, and the warehouse management system. Each of these bounded contexts would have their own specific models, language, and rules that are distinct from the other bounded contexts within the same subdomain.

In other words, a bounded context is a boundary within which a domain model is defined and applied. It represents a specific area of the domain where a specific team, department, or business unit has a clear and distinct responsibility. Each bounded context has its own models, entities, and operations, and may have different interpretations of the same concepts compared to other bounded contexts within the same domain.

Bounded contexts help to manage the complexity of large domains by breaking them down into smaller, more manageable pieces. They also help to ensure that teams can work independently and with clear boundaries, without interfering with each other’s work.

Duplication?

Yes, duplication can happen across bounded contexts, especially for entities that exist in multiple contexts but have different attributes or behavior. In such cases, it’s important to ensure that the duplication is intentional and does not violate the principles of DDD. It may be necessary to introduce a shared kernel or a domain library to reduce duplication and ensure consistency across bounded contexts. Additionally, good communication and collaboration between teams working on different bounded contexts can help to identify and address duplication early on.

Summary

Domains and subdomains are problem space concepts that focus on the specific areas of expertise or knowledge within a business or organization. They are defined by the business or organization and are based on their unique needs and requirements.

On the other hand, bounded contexts are solution space concepts that are used to organize and structure the software system that is being developed to solve the problems in the domain and subdomains. They help ensure that the software system is organized in a way that is aligned with the business or organizational requirements, while also being maintainable and adaptable over time.

• ddd
• faq