Domain-Driven Design—approach where business domain drives software design. Code reflects business language and rules.

What is a bounded context?

Boundary within which a domain model is consistent. Same term can mean different things in different contexts.

What is ubiquitous language?

Shared vocabulary between developers and domain experts. Same terms in code and conversation.

What is an aggregate?

Cluster of entities and value objects with root and consistency boundary. One transaction per aggregate.

Object with identity. Two entities with same data but different IDs are different.

What is a value object?

Object without identity. Two with same data are equal (e.g. Money, Address).

What is a domain event?

Something that happened in the domain (past tense). Used for decoupling and integration.

When domain is complex and business experts available. Not for simple CRUD.

What is aggregate root?

Entry point to aggregate. External code references only root; root enforces invariants.

How big should aggregate be?

Small for one transaction; large enough to enforce invariants. Split if concurrency issues.

What is anti-corruption layer?

Translation layer between your model and external/legacy system. Protects your domain.

How do aggregates communicate?

Via domain events. One publishes; another subscribes. Eventual consistency.

What is anemic domain model?

Entities with only data, no behavior. Avoid by putting behavior in aggregates.

How identify bounded contexts?

Talk to domain experts. Look for different meanings of same term. Align with teams.

Domain-Driven Design (DDD) Basics: Bounded

Introduction

This guidance is relevant when the topic of this article applies to your system or design choices; it breaks down when constraints or context differ. I’ve applied it in real projects and refined the takeaways over time (as of 2026).

Complex business domains are hard to get right when you start from the database or UI instead of the business language and rules. This article covers Domain-Driven Design (DDD) basics: bounded contexts, aggregates, entities, value objects, ubiquitous language, and when to use DDD in microservices and enterprise systems. For architects and tech leads, aligning code with domain boundaries and a shared language matters when domain complexity justifies it—not for every project.

For a deeper overview of this topic, explore the full Microservices Architecture guide.

Topics covered

Decision Context
What is DDD?
Strategic vs tactical DDD
Bounded contexts
Ubiquitous language
Aggregates
Entities vs value objects
Domain events
When to use DDD
Enterprise best practices
Common issues
Summary
Position & Rationale
Trade-Offs & Failure Modes
What Most Guides Miss
Decision Framework
Key Takeaways
When I Would Use This Again — and When I Wouldn’t
Frequently Asked Questions

Decision Context

System scale: Systems with non-trivial domain logic and multiple subdomains; from medium to large applications. Applies when the domain is complex enough that a shared model and language pay off.
Team size: Teams that can work with domain experts and maintain a shared vocabulary; someone must own bounded contexts and aggregate boundaries. Works when the business logic is not “simple CRUD.”
Time / budget pressure: Fits when you have time for discovery and iterative modelling; breaks down when the domain is trivial or when there’s no access to domain experts—then a simpler model is better.
Technical constraints: Any stack; DDD is about modelling and boundaries, not a specific technology. Assumes you can separate domain from infrastructure (e.g. repositories, persistence).
Non-goals: This article does not optimise for “DDD everywhere”; it focuses on when DDD is justified and how to apply bounded contexts and aggregates.

What is DDD?

Domain-Driven Design is an approach where:

The domain (business problem) drives the design
Code reflects business language and concepts
Complex domains are split into bounded contexts
Aggregates enforce business rules and consistency

DDD Concept	Purpose
Bounded Context	Boundary where a model is consistent
Ubiquitous Language	Shared vocabulary between devs and domain experts
Aggregate	Cluster of objects with consistency boundary
Entity	Object with identity (e.g. Order)
Value Object	Object without identity (e.g. Money, Address)
Domain Event	Something that happened in the domain

Strategic vs tactical DDD

Strategic DDD is about the big picture:

Identifying bounded contexts
Defining context relationships
Aligning teams with contexts

Tactical DDD is about implementation:

Aggregates, entities, value objects
Domain services, repositories
Domain events

Start with strategic to understand boundaries; use tactical for implementation.

Bounded contexts

A bounded context is a boundary within which a domain model is consistent. The same term can mean different things in different contexts:

Concept	Sales Context	Shipping Context
Order	Quote, pricing, customer	Package, address, carrier
Customer	Billing info, credit	Delivery address only
Product	SKU, price	Weight, dimensions

Each context has its own model. Do not force one model to fit all contexts.

Context mapping defines relationships between contexts:

Shared Kernel: Shared code/model (tight coupling)
Customer-Supplier: One context depends on another
Anti-Corruption Layer: Translate between models

Ubiquitous language

Ubiquitous language is a shared vocabulary between developers and domain experts. Everyone uses the same terms in code, docs, and conversations.

Examples:

“Order” not “purchase_record”
“Ship” not “update_status_to_shipped”
“PlaceOrder” not “createOrderRecord”

Code should read like business language:

// Good: ubiquitous language
order.Place();
order.Ship();
order.Cancel();

// Bad: technical jargon
order.SetStatus(OrderStatus.Placed);
orderRepository.Update(order);

Aggregates

An aggregate is a cluster of entities and value objects with:

A root entity (aggregate root)
A consistency boundary
Invariants (rules that must always be true)

Rules:

External references only to the root
Changes go through the root
One transaction = one aggregate

Example: Order aggregate

// Order is the aggregate root
public class Order
{
    public OrderId Id { get; }
    public CustomerId CustomerId { get; }
    private readonly List<OrderLine> _lines = new();
    public IReadOnlyList<OrderLine> Lines => _lines;
    
    // Invariant: order total cannot be negative
    public Money Total => _lines.Sum(l => l.Subtotal);
    
    // Changes go through the root
    public void AddLine(ProductId productId, int quantity, Money price)
    {
        if (quantity <= 0) throw new DomainException("Quantity must be positive");
        _lines.Add(new OrderLine(productId, quantity, price));
    }
    
    public void Place()
    {
        if (!_lines.Any()) throw new DomainException("Cannot place empty order");
        // Raise domain event
    }
}

Entities vs value objects

Aspect	Entity	Value Object
Identity	Has unique ID	No identity
Equality	By ID	By value
Mutability	Can change	Immutable
Examples	Order, Customer, Product	Money, Address, DateRange

Entity example:

public class Customer
{
    public CustomerId Id { get; }
    public string Name { get; private set; }
    
    // Two customers with same name are different entities
    public override bool Equals(object obj) =>
        obj is Customer c && c.Id == Id;
}

Value object example:

public record Money(decimal Amount, string Currency)
{
    // Two Money with same amount and currency are equal
    public static Money operator +(Money a, Money b)
    {
        if (a.Currency != b.Currency) throw new InvalidOperationException();
        return new Money(a.Amount + b.Amount, a.Currency);
    }
}

public record Address(string Street, string City, string PostalCode, string Country);

Domain events

Domain events represent something that happened in the domain. They are past tense and immutable.

Examples:

OrderPlaced
PaymentReceived
CustomerAddressChanged

public record OrderPlaced(OrderId OrderId, CustomerId CustomerId, DateTime OccurredAt);

public class Order
{
    private readonly List<IDomainEvent> _events = new();
    
    public void Place()
    {
        // Validate...
        _events.Add(new OrderPlaced(Id, CustomerId, DateTime.UtcNow));
    }
    
    public IEnumerable<IDomainEvent> GetDomainEvents() => _events;
}

Events enable:

Decoupling between aggregates
Audit trails
Event sourcing
Integration between bounded contexts

When to use DDD

Use DDD when:

Domain is complex (many rules, edge cases)
Business experts are available
Long-term investment justifies upfront cost
Microservices need clear boundaries

Skip DDD when:

Simple CRUD application
No domain complexity
Tight deadlines, no domain expert access
Small team, small scope

DDD adds complexity. Use it where the domain justifies it.

Enterprise best practices

1. Start with strategic DDD. Identify bounded contexts before coding. Talk to domain experts.

2. One aggregate = one transaction. Do not span transactions across aggregates.

3. Keep aggregates small. Large aggregates have concurrency issues. Split if needed.

4. Use domain events for cross-aggregate communication. Do not reference other aggregates directly.

5. Protect invariants. Aggregates enforce business rules. Do not bypass with direct DB access.

6. Align bounded contexts with teams. One team owns one context. Conway’s Law.

7. Use anti-corruption layers. When integrating with legacy or external systems, translate to your model.

8. Iterate. Domain models evolve. Refactor as understanding improves.

Common issues

Issue	Cause	Fix
Anemic domain model	Logic in services, not entities	Move behavior into aggregates
Giant aggregate	Too much in one boundary	Split into smaller aggregates
Cross-aggregate transactions	Spanning multiple aggregates	Use eventual consistency, domain events
Leaky abstraction	DB concerns in domain	Use repository pattern; keep domain pure
Wrong bounded contexts	Misunderstood domain	Iterate with domain experts
Over-engineering	DDD for simple CRUD	Use DDD only where domain is complex

You can also explore more patterns in the Microservices Architecture resource page.

Summary

DDD aligns code with business domains: use bounded contexts to split complexity, ubiquitous language for shared understanding, and aggregates for consistency. Applying DDD everywhere leads to overkill on simple CRUD; applying it where domain complexity justifies it keeps models clear and teams aligned. Next, identify subdomains and where the same concept means different things in different parts of the business, then introduce one bounded context and iterate with domain experts.

Position & Rationale

I use DDD when the domain has real rules, multiple subdomains, and a need for a shared language between devs and business—so that the code and conversations use the same terms. I apply bounded contexts when the same concept means different things in different parts of the business (e.g. “order” in shipping vs billing); I avoid a single giant model. I use aggregates to enforce consistency boundaries and keep transactions small; I avoid cross-aggregate transactions and use domain events for eventual consistency. I skip DDD when the problem is simple CRUD or when there’s no domain complexity to capture—then a thin domain or anemic model is fine. I don’t do “DDD theatre” (ubiquitous language in name only, or aggregates that are just entity bags with no invariants).

Trade-Offs & Failure Modes

DDD adds upfront modelling and discipline; you gain alignment with the business and clearer boundaries. Bounded contexts add coordination (context maps, contracts); you gain freedom to evolve each context. Aggregates limit transaction scope; you gain consistency within the aggregate but must design for eventual consistency across aggregates. Failure modes: one huge aggregate (hard to reason about and deploy); cross-aggregate transactions (distributed monolith); bounded contexts that don’t match how the business thinks; over-engineering simple domains with full DDD ceremony.

What Most Guides Miss

Most guides explain entities and aggregates but don’t stress that aggregate boundaries are the hard part—too small and you have cross-aggregate consistency issues; too large and you have a monolith inside the boundary. Another gap: strategic DDD (bounded contexts, context mapping) is often skipped in favour of tactical (entities, value objects); without strategic DDD you get a single model that tries to be everything. When not to use DDD is underplayed—simple CRUD or thin domains don’t need aggregates and ubiquitous language; applying DDD there is overhead.

Decision Framework

If the domain has distinct subdomains and the same term means different things in different areas → Use bounded contexts; define context map and contracts.
If there are consistency rules that must hold within a boundary → Model aggregates; keep transactions inside one aggregate; use events for cross-aggregate.
If the business and devs need a shared vocabulary → Cultivate ubiquitous language; use it in code and in conversation.
If the problem is simple CRUD or no real domain logic → Skip full DDD; use a simple model.
For existing systems → Start with one bounded context or one aggregate; expand iteratively with domain experts.

Key Takeaways

Use DDD when domain complexity justifies it—bounded contexts, ubiquitous language, and aggregates.
Bounded contexts split the model where the business splits; avoid one model to rule them all.
Aggregates enforce invariants and limit transaction scope; use domain events for cross-aggregate.
Skip DDD for simple CRUD; avoid giant aggregates and cross-aggregate transactions.
Iterate with domain experts; strategic DDD (contexts) before tactical (entities, value objects).

Need help designing resilient microservices? I support teams with domain boundaries, service decomposition, and distributed systems architecture.

When I Would Use This Again — and When I Wouldn’t

I’d use DDD again when the domain has real rules, multiple subdomains, and a need for a shared language—and when we have access to domain experts to refine bounded contexts and aggregates. I’d use bounded contexts when the same concept means different things in different parts of the system. I wouldn’t apply full DDD to simple CRUD or admin UIs where the domain is thin; the ceremony isn’t worth it. I also wouldn’t design one large aggregate “for simplicity”; small, well-defined aggregates with events are easier to evolve.

Waqas Ahmad — Software Architect & Technical Consultant

Distributed Systems

Article

Domain-Driven Design (DDD) Basics: Bounded Contexts and Aggregates

Read the article

Introduction

Topics covered

Decision Context

What is DDD?

Strategic vs tactical DDD

Bounded contexts

Ubiquitous language

Aggregates

Entities vs value objects

Domain events

When to use DDD

Enterprise best practices

Common issues

Summary

Position & Rationale

Trade-Offs & Failure Modes

What Most Guides Miss

Decision Framework

Key Takeaways

When I Would Use This Again — and When I Wouldn’t

Frequently Asked Questions

Frequently Asked Questions

What is DDD?

What is a bounded context?

What is ubiquitous language?

What is an aggregate?

What is an entity?

What is a value object?

What is a domain event?

When should I use DDD?

What is an aggregate root?

How big should an aggregate be?

What is strategic vs tactical DDD?

What is an anti-corruption layer?

How do aggregates communicate?

What is an anemic domain model?

How do I identify bounded contexts?

Related Guides & Resources

Related articles

Part of cluster

Related services