Design Philosophy: Domain-Driven Design

DDD as a thinking tool for aligning system architecture with business reality.

The Core Insight

Most systems fail not because of bad technology choices but because their structure doesn't match the problem they're solving. Domain-Driven Design is a response to that observation: the shape of your software should reflect the shape of your business domain.

This sounds obvious. In practice, it's rare. Most codebases are organized around technical concerns (controllers, services, repositories) rather than domain concepts (orders, shipments, policies). The result is code where you can't find the business logic — it's scattered across layers, buried in translation code, and duplicated in ways that diverge over time.

DDD provides a set of thinking tools for fixing that. Some are strategic (how to draw boundaries), some are tactical (how to model within a boundary), and the community is guilty of conflating the two. The strategic tools are almost universally valuable. The tactical tools are situational.

This skill focuses on applying DDD to real architecture decisions. Not a glossary of Evans-book terminology — a thinking framework for when you're staring at a system that doesn't make sense and need to figure out where the boundaries should be.

1. Ubiquitous Language

The Principle

Every bounded context should have a language shared by developers, domain experts, product managers, and the code itself. The same words appear in conversations, user stories, class names, database columns, and API contracts. No translation. No "well, in the code we call it X but the business calls it Y."

This is the most important idea in DDD, and the one most teams skip because it feels soft. It isn't.

Why It Matters Architecturally

Language mismatches are the leading indicator of boundary problems. When developers need a mental mapping table between business terms and code terms, one of two things is true:

1. The code is modeling the wrong abstraction. The business says "policy" and the code says rule_set — and over time, the code drifts because the developers don't attend the meetings where "policy" semantics get refined.
2. You have two bounded contexts pretending to be one. The word "account" means one thing to the billing team and another to the identity team, but they share a table and both are confused.

The Practical Discipline

• If you can't name it in the domain, you don't understand it. Before writing code, you should be able to explain the concept to a domain expert using the same words that will appear in your code. If you can't, stop and go learn the domain.
• The code is the source of truth for the language. If a product manager says "let's add a discount" and your code has PriceAdjustment, Rebate, PromoCode, and CouponRedemption, your ubiquitous language has collapsed. Choose one term and make everyone use it.
• Language boundaries reveal system boundaries. When you notice that two teams use the same word to mean different things, you've found a bounded context boundary. Don't paper over it with a shared glossary — model it as two separate concepts.
• Translation layers are technical debt. Every toBusinessModel() / fromBusinessModel() adapter is a place where meaning gets lost. Some translation is inevitable (at context boundaries), but translation within a context means the model is wrong.

What to Watch For

A team that can't agree on what to call something is a team that hasn't agreed on what it does. Naming debates aren't bikeshedding — they're domain modeling. Take them seriously.

2. Bounded Contexts

The Principle

A bounded context is a linguistic and model boundary. Within a bounded context, every term has exactly one meaning, and the domain model is internally consistent. Across bounded contexts, the same word can (and often does) mean different things.

…