When the software model and the business model speak different languages, every requirement crosses a translation layer where information gets lost. The developer interprets what the business wants. The business receives what the developer understood. The difference between the two versions accumulates as rework, interpretation bugs and features that technically work but do not solve the problem that motivated the request. That cost shows up nowhere in a sprint report. It appears as velocity that falls and alignment meetings that consume capacity without delivering result.
Subcapability 02 of 05 · Software Engineering & Architecture
Domain-Driven Design
Domain-Driven Design strategic layer with bounded contexts, ubiquitous language and Event Storming that eliminates the translation layer between business and code, reducing rework and containing domain change cost.
What is at stake
Developers and the business use the same words with different meanings. What the commercial team calls a "customer" is not what the financial team calls a "customer." Every alignment meeting repeats the same discussion. Every delivered feature requires an adjustment round because the code model does not reflect the business model. The rework does not show up in the report. It shows up in the lead time that never closes.
What it is, in practice
How we work
Strategic domain mapping
We identify business subdomains, classify what is the differentiating core and what is generic support, and draw the Context Map that defines how each part integrates. This strategic view guides where to invest modeling rigor and where to adopt off-the-shelf solutions.
Shared ubiquitous language
We build a domain terms glossary with definitions agreed between technical teams and business specialists. Ubiquitous language is used in code, in conversations and in documents, eliminating the translation layer where the cost of ambiguity accumulates.
Bounded contexts with explicit boundaries
We define where each model begins and ends, what data each context owns and how contexts communicate. Explicit boundaries allow teams to evolve their domain without constant coordination with other teams.
Collaborative Event Storming
We facilitate Event Storming sessions with business specialists and engineers to discover domain events, commands and aggregates without writing code. The result is shared understanding before any design decision.
Tactical DDD in critical bounded contexts
We apply Aggregates, Domain Events and Repositories in the contexts that concentrate the most complex and most frequently changing business logic, with economic criteria. Tactical DDD has implementation cost. We apply it where the return justifies.
Measurable gains
What changes in the result when this subcapability matures.
Rework from misinterpreted requirements
Ubiquitous language and bounded contexts with clear boundaries reduce the gap between what the business requested and what the team delivered. Alignment happens in modeling, before code, when adjustment cost is minimal.
Time for new engineer onboarding in the domain
Ubiquitous language glossary, documented Context Map and code that reflects business terms reduce the period where the new engineer learns the domain by trial and error and by dependency on whoever holds implicit knowledge.
Impact of a change in one context on other contexts
Bounded contexts with Anti-Corruption Layers and explicit contracts contain the side effect of change within the context boundaries. Teams change their domain without blocking coordination with other teams.
Lead time for changes in complex business logic
Code that directly reflects the business model reduces understanding time before any change. The engineer reads the code and understands the domain. Without that alignment, every change begins with reverse engineering what the code does versus what it should do.
Frequently asked questions
Does DDD apply to any system or only complex ones?
Strategic DDD, specifically bounded context mapping and ubiquitous language, is useful in any system with multiple teams working on the same product. Tactical DDD, with Aggregates, Domain Events and Repositories, has implementation cost that justifies itself in systems with complex business logic subject to frequent change. In simple systems with few rules, the implementation cost exceeds the isolation benefit.
What is a bounded context in practice?
A bounded context is the boundary where a specific model is valid and coherent. Within the sales bounded context, "customer" has a set of attributes and rules. Within the support bounded context, "customer" may have entirely different attributes and behaviors. Without that explicit boundary, both models collide in a single structure where each change request from one team breaks the expectation of the other.
How does Event Storming help discover the domain?
Event Storming starts with the events that happen in the business domain, written on orange sticky notes by business specialists and engineers together. From the events, it identifies the commands that cause them, the actors who issue the commands and the policies that connect events to new commands. The result is a domain timeline that exposes gaps in understanding before any architecture decision.
How does the Context Map influence system architecture?
The Context Map documents the relationships between bounded contexts and the integration type of each relationship. A Customer-Supplier relationship has different implications than a Shared Kernel relationship. An Anti-Corruption Layer isolates one context from the language and model of another. These integration decisions determine the actual coupling level between teams and systems, with direct impact on deployment autonomy and velocity of change.
How long does it take to implement DDD in an existing system?
Strategic mapping, Event Storming and bounded context identification can be done in one to two weeks for medium-complexity systems. Applying tactical DDD in existing code is an incremental process: each refactoring of a high-complexity module applies the patterns where the return is greatest. Full rewrite is rarely the path. The Strangler Fig Pattern isolates and replaces modules progressively.
Other subcapabilities in this capability
Evolutionary Architecture
Fitness functions, ADRs and evolutionary architecture principles that let the system absorb strategy changes without full rewrites and keep the cost of change quantifiable and within manageable limits.
Clean Architecture & Patterns
Clean Architecture Dependency Rule with Hexagonal Architecture, CQRS and Event Sourcing applied to the right contexts, allowing vendor and technology swaps without touching the business logic that matters.
Testing Strategy
Test Pyramid with Consumer-Driven Contracts via Pact and Mutation Testing that build genuine confidence to change production code and eliminate the fear ceremony that slows every release.
Code Quality & Craft
SonarQube Quality Gates, Technical Debt Ratio and Cognitive Complexity metrics that keep delivery velocity sustainable and prevent silent technical debt accumulation from becoming the invisible bottleneck of every future release.
Want clarity on where to invest first?
A complete technology capability assessment with an evolution roadmap connected to financial result.