A Model Can Grow in Complexity

Large models accommodate many domain concepts and carry out many business use cases. As a consequence, it is easy to make mistakes and group the wrong concepts together. It can also be very difficult to find what you are looking for. The more the system grows, the more severe these problems become, slowing down the speed at which new features and improvements can be added.

As Figure 6.1 highlights, with each new use case and insight incorporated into the model, the number of concepts and dependencies in the model grows, resulting in increased complexity.

Multiple Teams Working on a Single Model

Complex code is just one of the problems arising from a single model. Collaboration overhead and organizational inefficiencies are also major problems a monolithic model is likely to cause.

As one team wants to release a new feature, they have to check with other teams that their changes can also be deployed. Either the first team will have to wait, or complex branching strategies will be used. As Chapter 11, “Introduction to Bounded Context Integration,” explains in more detail, complex branching strategies can be a big hindrance to an organization’s ability to frequently and efficiently deliver business value and learn about their customers.

Continually requiring teams to collaborate on the design of new features or to plan releases is an unnecessary inefficiency. As each team works with their own domain expert and tries to drive their model in different directions, dragging other teams along with them is mutually wasteful. The more teams, the more expensive the collaboration overhead, and the more complex the codebase, as Figure 6.2 illustrates.

If multiple models are used instead, teams can iterate on their models and deliver new value frequently and efficiently because they do not have to synchronize with other teams or concern themselves with concepts from other teams’ models.

You may be concerned about a team’s duplicating code in each of their models. But focus on the benefits that arise by removing dependencies between teams. Essentially, it is Ok to duplicate code between models because the concepts are not the same.

Ambiguity in the Language of the Model

One of the epiphanies that DDD practitioners have is the realization that some concepts in a system are very similar—they might even have the same name. Yet actually, they mean very different things to different parts of the business. As Figure 6.3 illustrates, the “Ticket” concept means different things to the Sales and Customer Service departments.

Once you accept that names can have different meanings in different contexts, it’s easier to accept that multiple smaller models are more effective than a single large one. You can also have more meaningful discussions with domain experts. For example, based on Figure 6.3, when talking to the Sales manager about tickets, you know she cares about the cost and location of an event; whereas discussion about tickets with the Customer Service manager will be focused on the severity and category of problems raised by customers.

The Applicability of a Domain Concept

Sometimes, a single physical entity in the problem domain can mistakenly be classified as a single concept in code. This is problematic when the physical entity actually represents multiple concepts, that each mean different things in different contexts. The classic example is a product.

Figure 6.4 shows how products mean different things in different contexts. It is a concept that must be acquired with a profitable margin and acceptable lead time to the Procurement team. Yet to the Sales team a product is a concept with images, size guides, and belongs to a selling category—none of which are relevant to the Procurement team, even though it is the same physical entity in the problem domain.

When a physical entity, such as a product, actually represents multiple domain concepts, it is often modeled as a single concept by developers. Unfortunately, it’s very easy to fall into the trap of thinking that because a product can be a physical item that it should be modeled as a single class in code. This leads to coupling, as each model shares the same product class, as shown in Figure 6.5.

As discussed previously, when multiple contexts are coupled, code can become excessively complex and the collaboration overhead between teams can become excessively costly. The shared class, in this example product, also violates the Single Responsibility Principle (SRP), since there are four contexts that all want it to change for completely different reasons.

When there are no boundaries in the code, it is too easy for coupling to occur, as with the product shown in Figure 6.5. A better solution that reduces the coupling would be for each context—Promotion, Allocation, Loyalty, and Shipping—to have its own model. Each model would then contain a unique representation of a product that only satisfies the needs of the model’s context. Figure 6.6 shows the multiple responsibilities of the shared Product class, indicating which model each of them should really belong in.

Integration with Legacy Code or Third Party Code

Another reason to prefer smaller models is that integrating with legacy code or third parties can be less problematic. Adding new features to a monolithic codebase can be painful when there is lots of legacy code. You want to add clean, new, insightful models that you created with domain experts, but the limitations of legacy code can constrain the expressiveness of your design. But if you have smaller models, not all of them will need to touch the legacy code.

A number of patterns, discussed in Chapter 11, show how it is easier to apply DDD to legacy systems when you have multiple smaller models to work with.

Your Domain Model Is not Your Enterprise Model

Having a single model of the entire system is useful in some scenarios, including business information (BI) and reporting. However, the enterprise model is not the best solution for creating an evolvable domain model that explicitly expresses domain concepts. Nor is an enterprise model suitable for iterative development processes that aim to deliver business value frequently delete repetition.

Figure 6.7 shows how you can have the best of both worlds—a unique model for each context and an enterprise model for BI.

Defining a Model’s Boundary

The need for bounded contexts is clear in larger systems, but the process of identifying bounded contexts and their boundaries is challenging. Fortunately, it’s not an up-front decision you have to get perfectly correct. As you learn more about the domain, you can adjust the boundaries of your bounded contexts.

There are two aspects of a problem domain that you can use as a guide to identifying bounded contexts—terminology and business capabilities. As you’ve seen previously in this chapter, the same term can have different semantics in different contexts. If you can delineate a domain model based on a change in the meaning of a word or phrase, you will very likely have identified the boundary of a bounded context. Business capabilities are often easy to discern but can be misleading. For example, if a business has a Sales department and a Customer Service department, there is very likely to be a sales and customer bounded context. But that’s not always true, so it’s important not to blindly model business capabilities.

Outside of the problem domain, team structure and location can also be a big influence on context boundaries, as can integrating with legacy or third-party systems.

Size, though, is not a guideline for delineating bounded contexts. No absolute or relative value can tell you how many classes or lines of code you need. A bounded context’s size is dependent mostly on aspects of the problem domain. Some bounded contexts may, therefore, be large while others are small.

To summarize, context boundaries can be influenced by the following:

• Ambiguity in terminology and concepts of the domain
• Alignment to subdomains and business capabilities
• Team organization and physical location
• Legacy code base
• Third party integration

The Difference between a Subdomain and a Bounded Context

Subdomains, introduced in Chapter 3, “Focusing on the Core Domain,” represent the logical areas of a problem domain, typically reflecting the business capabilities of the business organizational structure. They are used to distinguish the areas of importance in an application, the core domain, from the less important areas, the supporting and generic domains. Subdomains exist to distill the problem space and break down complexity.

Domain models are built to fulfill the uses cases of each of the subdomains. Ideally there would be a one-to-one mapping between models and subdomains, but this is not always the case. Models are defined based on team structure, ambiguity in language, business process alignment, or physical deployment. Therefore a subdomain could contain more than a single model and a model could span more than a single subdomain. This is often the case within legacy environments.

Models need to be isolated and defined within an explicit context in order to stay pure and focused. As you’ve learned, this context is known as the bounded context. Unlike a subdomain, a bounded context is a concrete technical implementation that enforces boundaries between models within an application. Bounded contexts exist in the solution space and are represented as explicit domain models in a context.