liveBook · Manning

Supporting subdomain

As explained in Architecture Modernization: Socio-technical alignment of software, strategy, and structure

A supporting domain is a business domain that enables core business capabilities without being a primary source of competitive differentiation.

A supporting subdomain helps a business deliver its core capabilities without being a major source of differentiation on its own. It sits between a core domain, where distinctive capabilities justify substantial investment, and a generic subdomain, where an off-the-shelf solution may suffice. Supporting subdomains usually contain company- or industry-specific logic, so they are typically built in-house. section 10.2 section 10.5

A capability that unlocks another

For a shared-scooter company, better placement planning could become a lasting source of differentiation. But more dynamic placement also depends on scooter placement logistics: software and technicians must move scooters where they are needed. Investing in this supporting subdomain enables the core opportunity, even though moving scooters is not itself the distinctive offer. section 10.2.1

Supporting does not mean simple, inexpensive, or safe to neglect. Scooter journeys, for example, is a supporting subdomain that must operate reliably at scale: downtime prevents riders from taking journeys. Model complexity and operational demands are worth discussing separately when deciding how to invest. section 10.2.1 section 10.5

Use a Core Domain Chart to make the investment decision collaboratively:

  • Bring business, product, domain, and technical perspectives together to place subdomains by differentiation and model complexity. section 10.2
  • Discuss each subdomain’s challenges and opportunities; use arrows to show a possible investment or change over time. section 10.2.4 section 10.5
  • Ask whether improving a supporting subdomain would unlock a core capability, remove costly work, or make its software easier to evolve. section 10.2.1 section 10.2.4

Choosing the first modernization step

At an events scale-up, two core domains initially looked like the strongest investments. The group instead chose a supporting subdomain first. Improving it would remove a slow manual process, reduce operational costs, and give a team a chance to model a domain whose code had been scattered across codebases. The choice addressed a business bottleneck while preparing the organization for further change. section 10.2.4

Figure 10.8 Three subdomains shortlisted for the first modernization step

The shortlisted-subdomains chart contrasts investment in two core domains with an arrow toward lower complexity for the chosen supporting subdomain. section 10.2.4

How Architecture Modernization: Socio-technical alignment of software, strategy, and structure covers it

How deep it goes
Explains classification and investment through charting and organizational examples, without prescribing software implementation steps.
Examples
Uses scooter placement logistics, scooter journeys, and an events scale-up’s modernization shortlist.
What it assumes
Introduces the three DDD subdomain categories while relying on collaborators to discuss their business subdomains and relative complexity.
What you can do after
Apply it via a Core Domain Chart to weigh supporting-subdomain investment against core-domain opportunities.
How it connects
Connects supporting subdomains to core domains, generic subdomains, Core Domain Charts, model complexity, and operational complexity.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Architecture Modernization: Socio-technical alignment of software, strategy, and structure. The section links point to the parts of the book it draws on.