Skip to content

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. The first chapter sets a compelling stage: DDD is fundamentally about effective communication and aligning software design with business strategy.

Here are my key takeaways from Chapter 1.

Strategic vs. Tactical Design

DDD addresses software complexity from two angles:

  • Strategic Design: Answers “what” we are building and “why”. It focuses on analyzing business domains, strategy, and fostering a shared understanding between stakeholders and engineers.
  • Tactical Design: Answers the “how”. These are the patterns that allow us to write code reflecting the business domain and addressing its goals in the language of the business.

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 distinct types:

1. Core Subdomains

This is where the magic happens. A core subdomain represents what a company does differently from its competitors. It’s the source of competitive advantage. Because it provides this unique edge, it is naturally complex. 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). While difficult to implement, they do not provide a competitive edge. The golden rule here is to avoid building these in-house whenever possible. It is much more cost-effective to use existing, solved solutions.

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 consume the lion’s share of engineering innovation.

The Goal of Boundary Identification

When analyzing a business, the goal isn’t just to map everything perfectly, but to identify the boundaries that help us make better software design decisions. It’s crucial to distinguish between business functions that require custom software innovation (Core) and those that don’t (Generic and Supporting).

This simple tri-part breakdown forces a critical question: Are we spending our most expensive engineering effort on the things that actually differentiate our business?

I’m looking forward to seeing how these strategic foundations inform the tactical code patterns in the chapters ahead.