Volatility

The integration strength dimension reflects the likelihood of a change in a component propagating across its boundaries, while distance determines the cost of implementing a cascading change. The third dimension–volatility–reflects the probability of components needing to change in the first place. The higher the volatility, the more acute and “painful” design issues will be.

Predicting the future is impossible, but several models can shed light on a component’s plausible rate of future changes. One of them is domain-driven design’s concept of subdomains.

Domain-Driven Design’s Subdomains

According to domain-driven design (DDD), a company’s business domain is composed of business building blocks: subdomains. A subdomain is a rather fine-grained functionality essential for the company to succeed in its business domain. From a technical perspective, a subdomain can be seen as a set of interrelated use cases–use cases that are highly likely to change together.

DDD identifies three types of subdomains: core, generic, and supporting.

Core

Core subdomains are what differentiate the company from its competitors. These are the functionalities that provide a competitive advantage. Such functionalities need to be difficult for competitors to replicate and, as a result, often involve complexities in their problem space.

Generic

Generic subdomains are the opposite of core subdomains: they represent solved problems. These functionalities can be addressed by using off-the-shelf products, adopting open-source solutions, or utilizing software-as-a-service (SaaS) offerings.

Since companies and their competitors typically use the same generic solutions, generic subdomains provide no competitive edge.

Supporting

Like generic subdomains, supporting subdomains provide no competitive advantage. However, unlike generic subdomains, there are no ready-made solutions, meaning the company has to implement the required functionalities itself.

Unlike core subdomains, supporting subdomains are not complex; they typically involve CRUD data entry screens and ETL processes.

The differences between the three types of subdomains can be summarized in terms of the types of problems they represent:

Since only core subdomains provide a competitive advantage, they are the most volatile. Companies are continuously optimizing and improving their core subdomains to maintain their edge. Supporting and generic subdomains, on the other hand, are much less volatile.

Beyond DDD’s subdomains, other models can help predict the volatility of software components. For example, the commoditization axis in Wardley Maps provides another useful perspective.

Essential vs. Accidental (In)Volatility

As software engineers, we are naturally inclined to infer volatility by examining historical commit frequency. However, this method is prone to inaccuracies. A component’s source code may be frequently changed not because of the essential volatility of its business domain, but due to poor design: ineffective management of integration strength and distance can result in accidental volatility.

Conversely, some components in a system may appear involatile. However, the lack of change may not indicate stability–it could be due to poor codebase design. In such cases, the business may want to introduce changes, but the high risk and effort associated with modifying a poorly designed system prevent them from doing so.

Learn More