Exploring the Problem Space with Strategic Domain-Driven Design and Wardley Mapping

By Susanne Kaiser

Date: Feb 25, 2026

Sample Chapter is provided courtesy of Addison-Wesley.

Return to the article

The second perspective on designing and building adaptive, socio-technical systems involves Domain-Driven Design (DDD). DDD focuses on designing software based on domain models, as Eric Evans explained in his book Domain-Driven Design: Tackling Complexity in the Heart of Software [2.1]. The core concept of DDD is that to build better software, its design must align with the business domain, business needs, and business strategy. Before diving straight into developing a technical solution that solves the user needs, it’s necessary to understand the problem domain first, and that’s where DDD is especially beneficial.

Obtaining Domain Knowledge Through Collaboration

An essential part of DDD is collaboration between domain experts and development teams to analyze the problem domain to obtain shared domain knowledge. The problem domain (or business domain) refers to an organization’s scope or area of focus. In the example of the conference event planner solution introduced in Chapter 1, “Business Strategy with Wardley Mapping,” the problem domain or business domain is conference planning. The domain knowledge is described in terms of a shared, business-domain–oriented language—the ubiquitous language (Figure 2.1), which is free of any technical jargon.

DDD comes with many new terms that require some time to grasp and understand. The journey to DDD (and Wardley Mapping!) can be quite overwhelming. Yet, DDD provides a vocabulary for collaboration in strategic planning, making it worth the effort to learn. In this context, combining DDD with Wardley Mapping can be very helpful in the following ways:

• Using the context-specific visualization power of a Wardley Map provides an easy-to-follow gateway to DDD.

• DDD helps organizations apply the doctrinal principles of Wardley Mapping, enabling them to achieve organizational fitness to deal with strategic concerns and to adapt to changes quickly.

Chapter 3, “Designing the Solution Space with Strategic Domain-Driven Design,” addresses mapping bounded contexts to the evolution stages of a Wardley Map.

Domain-Driven Design Patterns and Practices

DDD entails a variety of patterns and practices consisting of strategic and tactical design. Figure 2.2 shows the Wardley Map adjusted for DDD by adding a layer to the y-axis of the map. This layer is not an official part of a Wardley Map itself. Instead, it is intended to provide an easy-to-follow path to enter the field of strategic and tactical design, going from the top—the strategic design patterns—to further down to the tactical design patterns. Please feel free to ignore this layer if it confuses you more than it helps.

Strategic and tactical design provides a set of patterns and practices to analyze and discover a problem domain and to design and implement a software solution fitting the problem domain as closely as possible. The top of the y-axis layer suggests starting in the problem space of strategic design. In connection with Wardley Mapping, the problem domain or business domain is composed of the users and their user needs. Even so, neither is redundant with the other. In the problem space of strategic design, analyzing the problem domain and discovering subdomains are essential. This chapter focuses on the problem space of strategic design.

Going further down, Figure 2.2 switches to the solution space of strategic design. While the problem space focuses on which problems to solve, the solution space concentrates on how to solve these problems. The solution space of strategic design is about making high-level design decisions, decomposing the system into modular components (the bounded contexts), and mapping the integrations between them (the context maps).

A step further down comes the stage of tactical design patterns. Tactical design patterns support low-level design decisions; the intent of these decisions is to design and implement a solution that fits the problem domain as closely as possible. Tactical design patterns provide building blocks to implement the domain model in code. While strategic design focuses on analyzing, discovering, decomposing, and mapping activities, the essential activities of tactical design are designing and implementing. Even though tactical design is included in Figure 2.2 as part of the added y-axis layer, it is typically not reflected as value chain components in a Wardley Map. It appears in the figure just as a means to visually demonstrate its classification.

Skipping the strategic design patterns and practices and going straight to tactical design creates a risk of implementing the solution of a barely understood problem domain and investing in parts providing undifferentiating value. It’s advisable to start with strategic design first to obtain the needed domain knowledge and identify where to prioritize the development efforts. Strategic design helps the organization analyze and understand the problem domain and discover the core domain so that it knows where to invest most strategically.

Discovering Subdomains and Mapping Their Evolution Stages

Distilling the business domain reduces complexity and increases understanding by partitioning the broad, abstract business domain into smaller, concrete parts—that is, into subdomains. Subdomains are subparts of the problem domain; however, not all subdomains are equal. Some are more strategically valuable to the business than others, as reflected by their types: core, supporting, and generic (Figure 2.3). Identifying these different types can help the organization find the subdomains and prioritize its strategic investments and development efforts. Discovering the subdomains splits a large domain into smaller, manageable parts and helps to identify the parts to invest in most strategically—namely, the core domains.

The Core Domain

The core domain is the essential, business-critical part of an organization’s problem domain. It usually provides the most value to customers and differentiates the organization from its competitors, giving it a competitive advantage. According to Michael Porter, organizations can achieve competitive advantage through either a differentiation advantage or a cost advantage [2.2]. A competitive advantage enables a company to compete effectively in its market and sustain long-term success.

A problem domain can embody one or sometimes more core domains. The core domain is typically complex, making it hard for competitors to copy or imitate it. It also tends to change quite often. The core domain is where the organization will most want to invest strategically and where it will have the most opportunity for innovation. In turn, the core domain is the focus of DDD efforts to understand and model it in detail. Strategically, it manifests the purpose of the business (the “why”) as described in Wardley’s strategy cycle.

The core domain is the subdomain for which software is typically evaluated for being built in-house. Initially, its solutions usually reside predominantly in the genesis or custom-built evolution stage of the Wardley Map, as its differentiators are still being explored. However, because the business landscape is dynamic, the core domain is subject to evolution, too. As the core domain matures and becomes more established in the market, it can evolve to the product evolution stage and potentially become a commodity. Moreover, as the core domain evolves, it becomes increasingly standardized. At this point, many companies might offer similar services, so the core domain becomes less differentiated from other products or services in the market.

Figure 2.4 depicts how the differentiation advantage decreases as the core domain evolves toward the right end of the spectrum of the Wardley Map, but the cost advantage can increase. Realizing a cost advantage is possible when a business can provide a product or service at a lower cost than its competitors. Organizations can lower their costs by reducing the cost of waste (such as defects, investments in unnecessary features, and waiting time) or by reducing the cost of deviation, which includes costs associated with failing to meet desired standards, requirements, or expected user outcomes.

According to Wardley’s doctrinal principles, everything is transient, and today’s core domain won’t perpetually remain core. Due to operating in a rapidly changing business environment, the core domain can become obsolete or be replaced by something new at some point in the future. This principle encourages organizations to be aware of changes and stay flexible and adaptive to remain competitive in the market.

In the context of the conference event planning solution, the user needs of managing the call for papers, submission handling, session evaluation, and schedule building belong to core domains (Figure 2.5). They represent the differentiating points from the organization’s competitors and play a major part in implementing their previously defined purpose of “helping to curate conference content.” Using or buying off-the-shelf products or outsourcing these parts of the conference event planning solution to utility suppliers could limit the organization’s ability to differentiate. Instead, custom-building the software for core domains in-house empowers the organization to deliver a specialized, differentiating solution, thereby creating a competitive difference. These core domains embody complexity because their solutions’ business logic goes beyond the rudimentary create–read–update–delete (CRUD) approach, and their enforced business rules require more than basic input validation.

The Supporting Subdomain

The supporting subdomain helps to support the core domain. The supporting subdomain does not provide a competitive advantage, tends to be simpler, and changes less frequently than the core domain. It might also exist in competitors’ products or services. In essence, the supporting subdomain is specialized but non-differentiating. If highly customizable products or open-source software solutions are available, buying or using existing products is a good approach for the supporting subdomain. In that case, the supporting subdomain predominantly resides in the product + rental evolution stage. If a higher level of specialization is necessary that cannot be productized, custom-building the software for the supporting subdomain may be justified—in which case, it goes into the custom-built evolution stage. However, the level of investment should not be too high under those circumstances. The supporting subdomain is necessary for the organization to succeed but provides no competitive advantage.

In the context of the aforementioned example of a conference event planning solution, communicating with the speakers—for example, answering questions through messages—could be a candidate for a supporting subdomain (see Figure 2.5). The messaging subdomain does not give the organization a competitive edge, but it supports the core domain’s success by facilitating interactions between the conference organizers and the speakers during the conference event planning process. This subdomain’s solution of sending messages back and forth tends to allow a rather simple CRUD approach with simple input validation, consisting of simple business logic. If some level of specialization is required, a simple custom-built solution, such as a CRUD-based implementation of the messaging subdomain with straightforward input validation and minimal business logic, can be entirely appropriate.

The Generic Subdomain

The generic subdomain is a subdomain that many business systems have (beyond the competitors’ problem domains), such as authentication or payment handling. Such a subdomain is ubiquitous in many business systems. Thus, the generic subdomains are not core to the business and do not provide a competitive advantage to the business, yet the business cannot work without them. Such subdomains are neither specialized nor differentiating. They could be complex, but their solutions have already been created by someone else. They tend not to change often and are fairly stable. Buying off-the-shelf products, using open-source software, or outsourcing to utility suppliers makes sense for generic subdomains. In turn, the generic subdomains’ solutions are predominantly located in the product + rental or commodity + utility evolution stage.

For the example conference event planning solution, ensuring secure access through signing in and signing up is a potential candidate for a generic subdomain (Figure 2.5). This subdomain is not core to the business, but the conference event planning solution does not work securely without registration and authentication. Many business systems need the same subdomain of registration and authentication. Its solution consists of complex business logic, but several products or services that address this need are readily available on the market. Recommended practice suggests that this subdomain use an open-source solution or outsource it to a cloud-hosted managed service. In addition, offloading this responsibility to existing solutions enables the organization to focus on the development effort for its core domains.

Table 2.1 summarizes the common tendencies in industry practice for each subdomain type; they serve as heuristics to guide evaluation, not strict prescriptions.

Table 2.1 Summary of Characteristics and Heuristics for Each Subdomain Type

	Core	Supporting	Generic
Differentiation	High	Low	Low
Domain complexity	High	Low–medium	Medium–high
Change rate	High	Low–medium	Low
Contribution to business purpose	High	Medium	Low
Ubiquity (across industries)	Low	Medium	High
Strategic investment	High	Low–medium	Low
Common evolution stages of subdomain’s solution	Genesis/custom-built	Custom-built/product (+ rental)	Product (+ rental)/commodity (+ utility)
Strong candidate for	Build in-house	Use/buy off-the-shelf products/open-source software or build in-house (if specialization required)	Use/buy off-the-shelf products/open-source software or outsource to utility suppliers

The evolution stages mapped to subdomain types in Figure 2.5 and the evolution characteristics (see Table 1.1) can help the organization initially determine the type of a particular subdomain. Be aware, however, that each component of a system is always in a state of change and evolves over time—and that also includes the subdomains.

Build-or-Buy Decisions with Subdomain Types and Evolution Stages

Wardley Mapping emphasizes that each evolution stage has different characteristics. Different characteristics require using different methods for a given evolution stage. Wardley suggests building components in the genesis and custom-built stages in-house using agile methods, buying off-the-shelf products or using open-source solutions for components in the product + rental stage using lean methods, or outsourcing components in the commodity stage to utility suppliers.¹ This doctrinal principle can be enriched with subdomain types from DDD.

DDD highlights that not all subdomains of a problem domain have equal strategic value—some contribute more significantly to the business’s differentiation than others. To reiterate, the differentiating core domains require high strategic investments and represent strong candidates for being built in-house, while the non-differentiating subdomains are well suited for utilizing existing solutions unless they demand a high level of specialization. Over time, the core domains can evolve from custom-built to the product stage and potentially become commodities.

Basing a “buy-versus-build” decision for a value-chain component solely on its location on the evolution axis risks overlooking its potential business-critical importance. For example, a cloud provider would not outsource its cloud services (or underlying data center) to another cloud provider simply because cloud services are generally commodities and should be outsourced. Instead, the cloud provider would rather build its cloud services in-house because they are core and business-critical to its business—even though the level of differentiation might have decreased as a utility service (see Figure 2.4). Outsourcing its core domain would limit the cloud provider’s differentiation opportunities and weaken its competitive advantage². Conversely, when the organization is custom-building commodities that are not core to its business, it often leads to suboptimal investments of strategic efforts.

Off-the-shelf products and open-source software solutions may not necessarily meet all of the organization’s requirements out of the box, but they generally offer configuration and customization options. However, over-customizing off-the-shelf products beyond their core purpose can be costly and bears the risk of loss of standardization, reduced flexibility, upgrade limitations, performance issues, accidental complexity, and so on. Their original benefit of efficiency could decrease with over-customization. One alternative to excessive customization of an off-the-shelf product is to restrict its usage to the intended, designed-for use cases and to develop a custom solution for any functionality that is not provided by the off-the-shelf product. Thus, build-or-buy decisions are sometimes not either build or buy (i.e., binary), but rather build and buy.

Summary

This chapter introduced the problem space of strategic design combined with Wardley Mapping, as summarized in Figure 2.7.

In the problem space of strategic design, domain experts and development teams analyze the problem domain. In connection with the value chain of a Wardley Map, the users and their user needs not only represent the anchor of the map, but also reflect the problem domain from a DDD perspective. The problem domain consists of subdomains. Not all subdomains are equally valuable to the business in terms of differentiation. The differentiating core domain is the business-critical subdomain of a problem domain, which provides the organization with a competitive advantage.

In this chapter, the Wardley Map of the conference event planner solution created in Chapter 1 was complemented with patterns from strategic design. This chapter analyzed the problem domain and discovered its corresponding core, supporting, and generic subdomains. The subdomain types mapped to the Wardley Map’s evolution stages help prioritize the strategic investment and support build–buy–outsource decisions for the subdomains’ solutions. Speaking of solutions, the next chapter addresses the solution space of strategic design.

© 2026 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240