What does strategy really mean in the context of software design? How does it connect to Domain-Driven Design (DDD), and how can it help us make better architectural decisions?
In this article, we’ll explore the idea of strategic design through the lens of DDD. We’ll define key concepts like Subdomain, Core Domain, and how strategic thinking helps prioritize technical effort. Along the way, we’ll follow a character named Frank as he tries to turn his passion into a sustainable business.
What Is Strategy?
Let’s begin with a working definition from Wikipedia:
Strategy is a general plan to achieve one or more long-term or overall goals under conditions of uncertainty.
In business, the goal is usually straightforward: generate sustainable income by offering something of value. But markets are unpredictable. Strategies are about making smart bets, aligning effort with opportunity, and maximizing your chances of success despite uncertainty.
Frank’s Strategic Vision for SHELF
Remember Frank from previous article? A lifelong book lover and self-taught cook, he dreams of combining these two passions into a single business. His initial idea? Open a bookstore. But traditional bookstores are everywhere. Competing in a saturated market with no differentiator is risky.
Frank refines his idea: a bookstore focused solely on cookbooks, curated by someone who deeply understands cooking. Not just a place to buy books, but a space to inspire and teach the art of cooking.
This is a strategy. It aligns personal expertise with a niche market, reducing competition and increasing perceived value.
Positioning Through Specialization
Frank’s niche - cookbook specialization - does more than reduce competition. It helps define the Core Domain of his business. In DDD terms, this is a powerful insight: businesses succeed when their software supports what they do best.
Strategic Design in Domain-Driven Design
Domain-Driven Design encourages breaking down the complexity of a business into manageable parts, each with its own characteristics and strategic role. These parts are called Subdomains.
Subdomain: A distinct part of the problem space that plays a specific role in achieving business goals.
There are three main types of Subdomains in DDD: Core, Supporting, and Generic. Each plays a different role and requires a different level of technical investment.
Core Domain
This is the heart of the business - what sets it apart from competitors. For SHELF, the Core Domain is the curated selection of exceptional cookbooks, handpicked for their originality and value.
- Technical insight: The software here must reflect unique workflows—perhaps a custom curation engine, review scoring, or recipe indexing.
- Coding approach: Custom development is often required. Frameworks offer little help because the logic is business-specific and critical to success.
My Advice: Treat Core Domain code as a first-class citizen. Pair your best developers with domain experts.
Supporting Subdomains
These enable the Core Domain but don’t differentiate the business directly. At SHELF, Frank maintains a review pipeline, an internal system to select books based on editorial recommendations.
- Technical insight: The workflow is specialized but not unique across industries.
- Coding approach: Off-the-shelf tools might cover parts of the workflow, but customization is often needed for integration or UX fit.
My Advice: Balance between reuse and customization. Optimize effort while keeping tight integration with the Core.
Generic Subdomains
These are commodity components - standardized across many industries and not specific to your business. Examples at SHELF include:
- E-commerce platform
- Customer reviews module
- Payment processing
- Technical insight: The logic is well-understood and documented.
- Coding approach: Adopt existing solutions (SaaS, open source, commercial packages) with minimal changes.
My Advice: Don’t reinvent the wheel. Use mature tools, and save time for where it matters.
Subdomains Are Contextual
One company’s Generic Subdomain may be another’s Core. Consider Shopify: their e-commerce engine is the very foundation of their business - a Core Domain.
In their case:
- Core: Store engine and checkout logic
- Supporting: Site builder and theme editor
- Generic: Logging, notifications, analytics
My Advice: Strategic design is relative. Always assess subdomains within your business context.
Visualizing the Subdomains
A simple diagram can help you map the subdomains:
+---------------------+
| Core Domain | <- Unique value (e.g., Cookbook curation)
+---------------------+
↑
|
+---------------------+
| Supporting Subdomain| <- Helps Core (e.g., Review pipeline)
+---------------------+
↑
|
+---------------------+
| Generic Subdomain | <- Commodity (e.g., E-commerce)
+---------------------+This hierarchy also reflects how much effort and custom code each area typically requires.
Reflective Questions
To apply these ideas in your own project, ask:
- What makes your business different?
- Which parts of your system directly support that difference?
- Where should you invest your best design and development resources?
- What parts can be outsourced, licensed, or reused?
Summary
Domain-Driven Design isn’t just about modeling, it’s about strategic focus. Subdomains help you structure that focus.
- Core Domain: Your competitive edge. Code it with care.
- Supporting Subdomain: Important but not unique. Balance build vs. buy.
- Generic Subdomain: Standardized. Don’t waste time here.
The key to software success lies in making clear decisions about where to innovate and where to standardize. — Strategic Design, distilled from DDD