A domain model is a conceptual model based on the domain and includes both behaviors and data. It represents a part of the overall solution that fulfills the goals of the business. Bounded contexts are a pattern in DDD that represent partitions in the domain model. Similar to subdomains, which are partitions in the domain, bounded contexts are partitions in the domain model. As is the case with subdomains, creating partitions and boundaries reduces the overall complexity.
A bounded context may map to a single subdomain, but keep in mind that is not always the case. The domain model for a subdomain may require multiple bounded contexts for the overall solution of that subdomain.
For example, if we were creating a software system for a business that sells clothing online, we might allow customers to sign up for a newsletter that contains deals and discounts. Another part of the application would allow customers to place orders and provide payment information.
With these two pieces of functionality, some concepts are shared, while some are not. If different development teams, or different developers on a single team, are working on these two sets of functionality, it is not clear what overlap, if any, exists. If there is overlap, what should or should not be shared between these two pieces of functionality? This is where the concept of bounded contexts is applicable. A domain model applies to a particular context, so we can define the various contexts to clear up some of the ambiguities that exist.
In this example, we could create one bounded context for marketing (Marketing Context), and one for order processing (Order Processing Context). Each bounded context may have entities that are unique to itself. For example, the Order Processing Context has the concept of an order line item, whereas the Contact Management Context does not. However, both bounded contexts have the concept of a Customer. Is Customer referring to the same concept in both bounded contexts? By separating them out, we can begin to answer this question:
In the context of marketing, all that may be required for a Customer entity is an identity (unique identifier), first name, last name, and email address. However, in the context of placing an order, the Customer entity would require additional information, such as a shipping address and payment information.
You could create one Customer entity, but using it for different contexts adds complexity and can lead to inconsistencies. Validation that requires payment information only applies in the Order Processing Context, and not the Marketing Context. The behavior required for a Customer in the Order Processing Context should not prevent a Customer from being created in the Marketing Context, where only the first name, last name, and email address are required.
We will discuss the single responsibility principle (SRP) later in this book, but the basic idea is that each class should be responsible for a single aspect of the functionality. The Customer entity is still small now, but you can begin to see how it could grow quickly. If it were to be used in multiple contexts, it would attempt to fulfill too many disparate responsibilities and break the SRP.
The context for each model should be clearly defined and there should be an explicit boundary between bounded contexts. They are created so that everyone on the team, or across multiple teams, can have the same understanding of what belongs in each context. While the example used is a simplistic one, a large domain model will have many entities and contexts, and it usually isn't immediately clear what is unique or common across different contexts, and how each context should interact with each other.
DDD and the concept of bounded contexts work well with microservices, which we will be discussing in further detail later in this book. Now that we have a better understanding of DDD concepts, let's go into detail about requirements. Working with domain experts and other stakeholders, we need to have an understanding of the requirements prior to design.