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

This chapter is from the book

Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies

Learn More Buy

This chapter is from the book

This chapter is from the book 

Architecture for Flow: Adaptive Systems with Domain-Driven Design, Wardley Mapping, and Team Topologies

Learn More Buy

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.

Figure 2.3 The subdomain types and typical evolution stages of their solutions

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.

Figure 2.4 An evolving core domain with a decreasing differentiation advantage and an increasing cost advantage

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.

Figure 2.5 Core, supporting, and generic subdomains of the conference event planning example

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

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.