Build Software That Reflects Your Business Reality

What is Domain-Driven Design?

Domain-Driven Design (DDD) is an approach to software development that prioritizes deep understanding of the business domain. Introduced by Eric Evans in his 2003 book "Domain-Driven Design: Tackling Complexity in the Heart of Software," DDD provides patterns and practices for building software that accurately reflects complex business realities.

At its core, DDD recognizes that software complexity often reflects business complexity. When developers don't understand the domain they're modeling, they build the wrong abstractions. The result is software that's hard to maintain, difficult to evolve, and doesn't solve the right problems.

DDD addresses this by placing the domain model at the center of development. Domain experts and developers collaborate closely, speaking a shared language—the ubiquitous language—that's reflected directly in code. The result is software that business stakeholders can understand and validate.

At Salt, we apply DDD principles when building complex software products and modernizing legacy systems. Our engineers are trained in both strategic and tactical DDD patterns, enabling us to tackle even the most complex business domains.

Strategic Design: The Big Picture

Strategic design in DDD focuses on the high-level structure of the system—how different parts of the domain relate to each other and how teams should be organized around them.

Subdomains

Every business domain can be decomposed into subdomains—distinct areas of knowledge and activity. DDD categorizes subdomains into three types:

• Core Domain: The most important part of your business—what gives you competitive advantage. This deserves the most investment and the best engineers.
• Supporting Subdomain: Necessary for the business but not differentiating. Important, but you don't need to be world-class here.
• Generic Subdomain: Solved problems that any business faces. Consider buying off-the-shelf or outsourcing.

Bounded Contexts

A Bounded Context is an explicit boundary within which a particular domain model applies. Within the boundary, terms have specific, consistent meanings. Across boundaries, the same term might mean different things.

For example, "Customer" in a Sales context might include lead scoring and purchase history. In a Support context, it might focus on ticket history and satisfaction scores. Each context maintains its own model optimized for its needs.

Context Mapping

Context Maps visualize relationships between bounded contexts. Common relationship patterns include:

• Partnership: Two contexts succeed or fail together, requiring close coordination
• Customer/Supplier: Upstream context provides what downstream needs
• Conformist: Downstream context adopts upstream's model as-is
• Anti-Corruption Layer: Translation layer protects one context from another's model
• Shared Kernel: Shared code between closely related contexts

Tactical Patterns: Building Blocks

Tactical patterns provide the building blocks for implementing domain models within a bounded context.

Entities

Entities are objects with a distinct identity that persists over time. Two entities with the same attributes are not equal if they have different identities. For example, two bank accounts with the same balance are different accounts.

Value Objects

Value Objects are defined by their attributes, not their identity. Two value objects with the same attributes are equal. Money, addresses, and date ranges are typical value objects. Value objects are immutable—changing an attribute creates a new value object.

Aggregates

Aggregates are clusters of entities and value objects that are treated as a single unit for data changes. Each aggregate has a root entity (the aggregate root) that controls access to other members. Aggregates enforce invariants—rules that must always be true within the boundary.

Domain Events

Domain Events capture something important that happened in the domain. They enable loose coupling between aggregates and bounded contexts. When one aggregate changes, it publishes an event that other parts of the system can react to without direct coupling.

Domain Services

Domain Services encapsulate domain logic that doesn't naturally belong to an entity or value object—typically operations involving multiple aggregates or external systems.

Repositories

Repositories provide collection-like interfaces for accessing aggregates. They abstract persistence details, allowing the domain model to remain pure. Code interacts with repositories using domain concepts, not database queries.

Event Storming: Collaborative Domain Discovery

Event Storming, created by Alberto Brandolini, is a workshop technique for exploring complex business domains. It brings together domain experts and developers to build shared understanding through visual modeling.

How Event Storming Works

Participants use colored sticky notes on a long paper roll to model the domain:

• Orange (Domain Events): Things that happen—past tense verbs like "Order Placed" or "Payment Received"
• Blue (Commands): Actions that trigger events—"Place Order" or "Process Payment"
• Yellow (Aggregates): Clusters of related data and behavior—Order, Customer, Payment
• Purple (Policies): Business rules that react to events and trigger commands
• Pink (External Systems): Systems outside the domain boundary
• Red (Hotspots): Areas of confusion, conflict, or complexity requiring discussion

Types of Event Storming Sessions

Big Picture: 2-3 hour sessions exploring the entire domain at a high level. Great for understanding scope and identifying bounded contexts.

Process Level: Deeper dive into specific processes. More detail, involving commands, aggregates, and policies. Typically follows Big Picture sessions.

Design Level: Detailed modeling focused on aggregate design and implementation details. Best done with developers who will build the system.

Bounded Contexts in Practice

Bounded Contexts are perhaps the most important concept in DDD. Getting context boundaries right determines whether your system scales gracefully or becomes a tangled mess.

Identifying Bounded Contexts

Context boundaries often align with organizational boundaries (Conway's Law), but not always. Look for:

• Language differences—same terms meaning different things
• Independent change rates—parts that evolve at different speeds
• Team boundaries—natural ownership divisions
• Data ownership—where does authoritative data live?
• Consistency requirements—what must be transactionally consistent?

Context Communication Patterns

Contexts need to communicate. The patterns used depend on coupling requirements:

Synchronous (APIs): Direct calls between contexts. Simple but creates runtime coupling. Use when immediate consistency is required.

Asynchronous (Events): Contexts publish events; others subscribe. Looser coupling, eventual consistency. Better for scale and resilience.

Anti-Corruption Layer: Translation layer that protects your domain model from external systems. Essential when integrating with legacy systems or third-party APIs.

Bounded Contexts and Microservices

Bounded contexts often map to microservices, but the relationship isn't one-to-one. A bounded context might be implemented as multiple services, or multiple small contexts might share a service. The key is that service boundaries respect context boundaries—a service shouldn't span multiple contexts.

Implementing DDD

DDD patterns can be implemented in any modern programming language. The key is keeping the domain model isolated from infrastructure concerns.

Clean/Hexagonal Architecture

DDD implementations typically use layered architectures that protect the domain:

• Domain Layer: Entities, value objects, aggregates, domain services. No dependencies on infrastructure.
• Application Layer: Use cases and orchestration. Depends on domain, not infrastructure.
• Infrastructure Layer: Database access, messaging, external APIs. Implements interfaces defined in domain/application layers.

CQRS and Event Sourcing

For complex domains, Command Query Responsibility Segregation (CQRS) separates read and write models. Event Sourcing stores state changes as a sequence of events rather than current state. These patterns add complexity but enable powerful capabilities like temporal queries and audit trails.

Testing Domain Models

Well-designed domain models are highly testable. Unit tests verify aggregate behavior and invariants. Domain events enable "given-when-then" style testing. Because the domain is isolated from infrastructure, tests run fast without databases or external services.

When to Use Domain-Driven Design

DDD is powerful but not universally applicable. It's most valuable when:

Good Candidates for DDD

• Complex business domains: Finance, healthcare, insurance, logistics—domains where business rules are intricate and getting them wrong is costly.
• Long-lived systems: Software that will evolve over years, not months. DDD's upfront investment pays dividends in maintainability.
• Multiple teams: When different teams need to work on the same system, bounded contexts enable autonomy.
• Legacy modernization: DDD patterns enable incremental migration from monoliths without big-bang rewrites.

When DDD May Be Overkill

• Simple CRUD applications: If the business logic is trivial, DDD adds unnecessary complexity.
• Short-lived projects: The investment in domain modeling doesn't pay off for throwaway prototypes.
• Technical domains: Infrastructure, tooling, and technical utilities rarely benefit from DDD.
• No domain expert access: DDD requires collaboration with people who understand the business deeply.

Why Salt for Domain-Driven Design?

Salt brings deep expertise in applying DDD to real-world software challenges. Here's what sets us apart:

Experienced Practitioners: Our architects and senior engineers have applied DDD patterns across diverse domains—fintech, healthcare, e-commerce, and SaaS platforms. We've seen what works and what doesn't in practice.

Full-Stack DDD Capability: From strategic assessment and Event Storming facilitation through tactical design and implementation, we handle the entire journey. No handoffs to different teams.

Pragmatic Approach: We don't apply DDD everywhere. We assess your domain complexity and use just enough DDD to solve your specific challenges. Sometimes that means full tactical implementation; sometimes just strategic context mapping.

Knowledge Transfer: We don't just build—we teach. Our engagements include training and coaching so your team can apply DDD independently. We aim to build capability, not dependency.

Integration with Modern Practices: DDD integrates with our SPARK™ framework and modern engineering practices—CI/CD, test automation, and microservices architecture.

Ready to tackle your domain complexity? Schedule a domain assessment with our team to discuss how DDD can transform how you build software.