What Are Problem Space and Solution Space in Domain-Driven Design?

In my previous article on DDD titled “What Means Domain in the Context of Domain-Driven Design?”, we explored the essential elements of DDD, specifically focusing on the importance of understanding domains, core and subdomains, and bounded contexts. This foundational knowledge is critical when applying what we call Strategic Design in DDD, a method that helps to streamline how we approach complex systems.

Strategic Design in the context of Domain-Driven Design is a high-level approach that guides the organization and structure of a software system. Rather than diving straight into coding and implementation details, Strategic Design encourages you to first understand the larger business domain. It helps you identify the various subdomains and bounded contexts, how they interact, and what is core to the business. By doing so, Strategic Design enables you to make informed decisions about where to focus your efforts, ensuring that the software aligns well with the business needs and can evolve more easily over time.

Today, we’re taking the next logical step. We’re going to talk about problem and solution spaces within DDD and delve into the topic of context maps. These elements are crucial for the practical application of Domain-Driven Design and will help you navigate the complexities of real-world projects more effectively. So, let’s get to it.

Problem Space and Solution Space

When learning Domain-Driven Design, it’s crucial to distinguish between two key areas: the problem space and the solution space. The problem space deals with identifying what business challenges you’re trying to solve and why they matter. The solution space focuses on how you’re going to solve those challenges through software implementation.

The Problem Space

In DDD, the problem space is essentially the landscape of business issues that you aim to tackle. Think of it as the terrain you need to navigate to deliver a new core domain effectively. In our “sell books online” example from the previous article, the problem space might involve challenges like optimizing inventory management, streamlining the user interface for better customer experience, or enhancing the recommendation engine for increased sales.

Evaluating the problem space means looking at existing subdomains as well as identifying new ones that need to be developed. Here, subdomains act as building blocks for your core domain. For instance, in our online bookstore, the subdomains could be Catalog, Orders, and Invoicing, as already discussed in my previous DDD article.

The problem space is a combination of the Core Domain and Subdomains. That means that your central business objective (selling books online, in this case) can’t exist in isolation. It’s inherently tied to various sub-aspects like Invoicing, Shipping, and Orders, each a subdomain in its own right. Furthermore, subdomains often differ from one project to another because they serve to address current strategic business problems. In a different project, for example, the focus might shift from inventory management to global expansion and currency handling.

The Solution Space

This is where Bounded Contexts come into play. Once we have a clear understanding of the problem space, we move on to the solution space. This is where bounded contexts become essential. Each bounded context is a specific software model tailored to address elements within your problem space.

In the context of our online bookstore, one bounded context might deal exclusively with inventory management, ensuring that books are in stock and properly cataloged. Another might focus solely on the user interface, working to provide the customers with an intuitive and engaging shopping experience. Each of these bounded contexts is a specialized solution aimed at solving a specific problem within the larger domain.

Understanding the Vision

Understanding the vision and goals for your core domain is paramount.

If you don’t fully grasp these, along with the subdomains that support them, you’re missing a crucial piece of the puzzle. Without this understanding, it’s challenging to strategically leverage these elements to your advantage or steer clear of potential pitfalls.

Therefore, while your initial assessment of the problem space should remain high-level, it should also be comprehensive. This means you don’t need to dive into nitty-gritty details just yet, but you do need a broad understanding that covers all the bases. Ensure that all stakeholders — whether they’re on the business side or the technical side — are on the same page. Alignment and commitment across the board are key to successfully realizing the vision you’ve set for your domain.

Intersections Between Subdomains and Bounded Contexts

One of the most critical aspects to grasp in DDD is the intersection between subdomains in the problem space and bounded contexts in the solution space. The reason this is crucial is because it gives us the lens through which we can translate business challenges into actionable software solutions.

The Ideal Scenario: One-to-One Alignment

In a perfect world, each subdomain would align perfectly with a single bounded context. Such a one-to-one alignment elegantly compartmentalizes your domain models into well-defined areas, based on business objectives. This makes it easier to manage, both from a business and technical perspective.

In our “sell books online” example, let’s say our core domain is the Book Catalog. Ideally, the Book Catalog subdomain would align with a single bounded context dedicated solely to cataloging books — everything from managing inventory to categorizing genres to recommending reads. In the same vein, the Orders subdomain would align with a bounded context that takes care of everything order-related, like creation, tracking, and fulfillment.

Reality Check: Intersections and Overlaps

However, it’s worth acknowledging that we don’t always have the luxury of operating in ideal scenarios, particularly when dealing with legacy systems or when your architecture has grown into a “Big Ball of Mud”. In such cases, one subdomain might intersect multiple bounded contexts, or multiple bounded contexts might serve a single subdomain.

The term “Big Ball of Mud” refers to a software system that lacks a discernible architecture and has grown in complexity over time, making it challenging to manage or modify. It often results from organic growth and the absence of best practices in software development.

For instance, consider a complex legacy system in our online bookstore. The Orders subdomain might be splintered across multiple bounded contexts due to years of organic growth and patches. One bounded context might handle order creation, another order tracking, and yet another might manage returns and refunds. These bounded contexts might not be neatly contained but may intersect in various ways.

Conversely, our invoicing subdomain might consist of two bounded contexts: one for creating invoices and one for tax calculations. Both are part of the invoicing subdomain, but complex enough to merit their own bounded contexts.

The Process of Evolution

DDD is not a “do-it-once-and-forget-it” methodology. As your business grows and evolves, so will your subdomains and bounded contexts. What was once a one-to-one relationship may turn into an intricate web of intersecting bounded contexts and subdomains. This is perfectly normal and should be managed rather than avoided.

Brief Summary

Understanding the intersections between subdomains and bounded contexts is vital for successful DDD implementation. While a one-to-one alignment is the ideal, real-world scenarios often present us with complexities that require careful thought and flexible design. No matter how carefully we stake out our contexts or define our sub-domains, it is the intersection of these two areas that really determines how well your software meets your business goals.

Wrapping Up

In today’s discussion, we demystified this complexity by deeply diving into the mechanics of subdomains and bounded contexts. We used the online bookstore as a vivid example to explore what problem space and solution space mean. This breakdown not only helps you understand the broader structure of your domain, but also helps you manage its individual components more effectively.

As you tackle your own domain-driven projects, take the time to identify your problem space rigorously. Use that knowledge as a cornerstone to carve out your bounded contexts in the solution space, keeping in mind that real-world challenges might not always allow for a textbook-perfect mapping between subdomains and bounded contexts.