Deconstructing Strategic Design into Subdomains

I recently started reading Learning Domain-Driven Design by Vlad Khononov to deepen my understanding of how software architecture can better reflect business goals. Chapter 1’s argument, stripped of jargon: software gets easier to change when its structure mirrors how the business actually makes money. Everything else in DDD is downstream of that.

Strategic vs. Tactical Design

DDD splits the work into two angles. Strategic design answers what we’re building and why: analyzing the business domain and getting stakeholders and engineers onto a shared understanding of it. Tactical design answers how: the code-level patterns that let the implementation actually speak the business’s language.

The central premise is that the tighter the connection between software design and business strategy, the easier it is to maintain and evolve the system.

Deconstructing the Business Domain

A company’s main area of activity is its business domain. To manage complexity, this domain is broken down into smaller, more manageable pieces called subdomains. Khononov categorizes subdomains into three types:

1. Core Subdomains

A core subdomain is what a company does differently from its competitors: the work a competitor can’t just buy. It’s the source of competitive advantage, and naturally complex because of it. You don’t buy off-the-shelf software for a core subdomain; you build it to innovate.

2. Generic Subdomains

These are complex business activities that all companies perform in roughly the same way (e.g., authentication, payment processing). They’re difficult to implement, but solving them again gives you no competitive edge. The golden rule: don’t build these in-house if you can avoid it. It’s far cheaper to buy what’s already been solved.

3. Supporting Subdomains

These are necessary activities that support the company’s business but, unlike core subdomains, do not provide a competitive advantage. They often have obvious solutions. A company usually has to build these in-house, but they shouldn’t be where most of the engineering effort goes.

I’ve definitely shipped “core” work that, in hindsight, was supporting at best. The category isn’t decided by how hard the engineering felt — it’s decided by whether a competitor could buy the same outcome off the shelf.

The Goal of Boundary Identification

When analyzing a business, the goal isn’t a perfect map. It’s finding the boundaries that change software design decisions: which business functions require custom innovation (core), and which don’t (generic and supporting).

This breakdown forces one question:

Are we spending our most expensive engineering effort on the things that actually differentiate our business?

Onward to chapter 2, where the question becomes: once you’ve drawn these boundaries, how do you keep the language consistent across the people working on either side of them?

Part of the Learning Domain-Driven Design series.