What is Domain-Driven Design?

Domain-Driven Design (DDD) is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a business domain.

Strategic Design

Bounded Contexts

A bounded context is a explicit boundary within which a particular domain model is defined and applicable. Each bounded context has its own ubiquitous language and domain model.

Context Mapping

Understanding how bounded contexts relate to each other is crucial:

• Partnership: Two contexts cooperate closely
• Shared Kernel: Shared subset of the domain model
• Customer-Supplier: Upstream/downstream relationship
• Conformist: Downstream conforms to upstream model
• Anti-Corruption Layer: Translation layer between contexts

Ubiquitous Language

A common language between developers and domain experts that is used in all discussions, documentation, and code. This eliminates translation overhead and reduces misunderstandings.

Tactical Design

Entities

Objects defined by their identity rather than their attributes. An entity maintains continuity through its lifecycle.

public class Order {
    private readonly Guid _id;
    public Guid Id => _id;
    
    public Order(Guid id) {
        _id = id;
    }
}

Value Objects

Objects defined by their attributes, not identity. They are immutable and interchangeable.

public record Money(decimal Amount, string Currency);

Aggregates

A cluster of domain objects that can be treated as a single unit. Each aggregate has a root entity that serves as the entry point.

Domain Events

Something that happened in the domain that domain experts care about. Events enable loose coupling between aggregates.

Repositories

Provide collection-like interfaces for accessing aggregates. They abstract the underlying persistence mechanism.

Domain Services

Stateless operations that don't naturally fit within an entity or value object. They orchestrate domain logic across multiple aggregates.

Implementation Patterns

Event Sourcing

Store the state of an entity as a sequence of events rather than current state. Provides complete audit trail and temporal queries.

CQRS with DDD

Combine Command Query Responsibility Segregation with DDD for complex domains requiring different read and write models.

Common Pitfalls

• Anemic domain models with all logic in services
• Over-engineering simple domains
• Ignoring bounded context boundaries
• Not investing in ubiquitous language

Conclusion

DDD is not just a technical approach—it's a mindset shift toward collaboration with domain experts and creating software that truly models business complexity.