Aggregates - Learning Module

Loading content...

0/246

Consistency Boundaries

The Fundamental Tradeoff

Imagine an e-commerce system processing a flash sale. Thousands of customers simultaneously attempt to purchase from limited inventory. Each order must:

Reserve inventory items
Apply the customer's promotional code
Update the customer's loyalty points
Create a payment reservation

If you try to make all of these changes in a single atomic transaction, you'll face:

Lock contention: Multiple orders compete for the same inventory records
Deadlocks: Circular waiting as orders lock different resources
Throughput collapse: The system grinds to a halt under load

This scenario illustrates the fundamental tension in distributed systems: consistency versus scalability. Aggregates provide a principled solution by defining consistency boundaries—clear lines that separate what must be immediately consistent from what can be eventually consistent.

What You Will Learn

By the end of this page, you will understand how aggregates define consistency boundaries, the difference between immediate and eventual consistency, strategies for coordinating changes across aggregates, and how to design boundaries that balance correctness with scalability.

Understanding Consistency Boundaries

A consistency boundary is a line around a set of data that must be kept consistent at all times. Within the boundary, all changes are atomic—they all succeed or all fail. Outside the boundary, consistency is maintained through other mechanisms (events, sagas, compensation).

In DDD, the aggregate defines the consistency boundary.

This means:

All invariants within an aggregate are enforced synchronously
A single transaction modifies only one aggregate
Cross-aggregate consistency is achieved asynchronously

The Aggregate Rule

One transaction = One aggregate. This is the golden rule of aggregate design. Modifying multiple aggregates in a single transaction creates coupling, reduces throughput, and increases contention. Instead, design for eventual consistency across aggregates.

Converting Mermaid diagram...

Why This Matters

Consider the alternative—modifying multiple aggregates in one transaction:

// ❌ WRONG: Single transaction spanning multiple aggregates
transaction {
    order.confirm()           // Locks Order
    inventory.reserve(items)  // Locks Inventory  
    customer.addPoints(100)   // Locks Customer
    payment.authorize()       // Locks Payment
}

This approach has severe problems:

Lock duration: Transaction holds all locks until complete
Contention: Other orders can't modify any touched aggregate
Deadlock risk: Two orders might lock in opposite order
Failure blast radius: Any failure rolls back everything
Scaling limit: Throughput bounded by lock contention

Immediate vs Eventual Consistency

Understanding the difference between immediate and eventual consistency is crucial for aggregate boundary design.

Immediate Consistency

•Changes are atomic and synchronized
•All invariants enforced before transaction commits
•No window where data is inconsistent
•Required for critical business rules
•Achieved within a single aggregate
•Example: Order total = sum of items

Eventual Consistency

•Changes propagate asynchronously
•Temporary inconsistency is acceptable
•System converges to consistent state
•Suitable for non-critical cross-aggregate rules
•Achieved via events between aggregates
•Example: Customer loyalty points after order

The Key Question: What MUST be Immediately Consistent?

This question drives aggregate boundary decisions. Consider each business rule and ask:

What is the cost of temporary inconsistency?
- If inconsistency causes financial loss or safety issues → Immediate
- If inconsistency causes minor inconvenience → Eventual is fine
How long can we tolerate inconsistency?
- Milliseconds: Still needs immediate consistency
- Seconds to minutes: Eventual consistency usually acceptable
Can we detect and compensate for inconsistency?
- If yes: Eventual consistency with compensation
- If no: Immediate consistency required

Consistency Requirements by Business Rule
Business Rule	Consistency Type	Rationale
Order total = sum of items	Immediate	Incorrect total would charge wrong amount
Account balance ≥ 0	Immediate	Overdrafts have immediate financial impact
Inventory quantity ≥ 0	Immediate	Overselling creates fulfillment problems
Customer loyalty points update	Eventual	Delay of seconds is imperceptible to user
Product view count increment	Eventual	Exact count at any moment doesn't matter
Search index update	Eventual	Brief lag in search results is acceptable
Email notification	Eventual	Email delivery is inherently asynchronous
Analytics events	Eventual	Analytics tolerates seconds of delay

Default to Eventual Consistency

When in doubt, favor eventual consistency. Many 'must be immediate' requirements are actually just preferences. Challenge each requirement: 'What happens if there's a 5-second delay?' If the answer is 'nothing terrible,' eventual consistency is appropriate.

Designing Aggregate Boundaries

The aggregate boundary is perhaps the most important design decision in DDD. Get it wrong, and you'll face either:

Too large: Loading/saving is expensive, high contention, awkward API
Too small: Invariants span multiple aggregates, complex coordination required

The Decision Framework:

Aggregate Boundary Guidelines

•Start with invariants — Identify business rules that require immediate consistency. Objects that must satisfy the same invariant belong together.
•Consider lifecycle — Objects that are created/destroyed together belong in the same aggregate.
•Evaluate load patterns — If you always need A when you have B, they might belong together. If you rarely need both, separate them.
•Assess concurrency — High contention suggests the aggregate is too large. Split into smaller aggregates.
•Think about size — If loading the aggregate loads hundreds of objects, it's probably too large.
•Test with scenarios — Walk through use cases. Does the boundary feel natural or forced?

Example: Order Boundary Decision

Let's analyze what belongs in an Order aggregate:

Candidate	Same Aggregate?	Reasoning
OrderLines	✅ Yes	Order total invariant depends on lines
ShippingAddress	✅ Yes	Required for order confirmation invariant
Customer	❌ No	Independent lifecycle, shared across orders
Product	❌ No	Shared across many orders, independent lifecycle
PaymentInfo	⚠️ Depends	Could be internal (simple) or separate (complex payments)
OrderHistory	❌ No	Append-only log, no invariants with order

The key insight: OrderLines must be in the same aggregate as Order because the invariant "order total = sum of line totals" requires immediate consistency.

Aggregate Boundary Analysis
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
// ============================================
// EXAMPLE: E-Commerce Domain Aggregates
// ============================================
 
// Order Aggregate - defines the transaction/consistency boundary
// Includes: Order, OrderLines, ShippingAddress (value object)
class Order {
    private readonly _lines: Map<string, OrderLine> = new Map();
    private _shippingAddress: Address;
    private _status: OrderStatus;
    
    // Reference by ID to other aggregates
    private readonly _customerId: string;
    
    // Lines are INSIDE the boundary - immediate consistency
    addLine(productId: string, name: string, price: Money, qty: number): void {
        // Invariant checked immediately
        if (this._lines.size >= 50) {
            throw new Error("Maximum 50 items per order");
        }
        
        const line = OrderLine.create(/*...*/);
        this._lines.set(line.lineId, line);
        
        // Total is always consistent with lines (computed)
    }
    
    // Total invariant: enforced by computation, not storage
    calculateTotal(): Money {
        return Array.from(this._lines.values())
            .reduce((sum, line) => sum.add(line.lineTotal), Money.zero('USD'));
    }
}
 
// Product Aggregate - OUTSIDE Order's boundary
// Order references products by ID only
class Product {
    private readonly _productId: string;
    private _name: string;
    private _price: Money;
    private _stockQuantity: number;
    
    // Stock quantity is Product's consistency concern
    // Order can't directly modify this
    reserveStock(quantity: number): StockReservation {
        if (this._stockQuantity < quantity) {
            throw new Error("Insufficient stock");
        }
        this._stockQuantity -= quantity;
        return new StockReservation(this._productId, quantity);
    }
    
    releaseStock(quantity: number): void {
        this._stockQuantity += quantity;
    }
}
 
// Customer Aggregate - OUTSIDE Order's boundary
// Loyalty points are Customer's consistency concern
class Customer {
    private readonly _customerId: string;
    private _loyaltyPoints: number = 0;
    private _tier: CustomerTier = 'standard';
    
    // Points update is eventually consistent with order
    addLoyaltyPoints(points: number, orderId: string): void {
        this._loyaltyPoints += points;
        this.evaluateTierUpgrade();
    }
    
    private evaluateTierUpgrade(): void {
        if (this._loyaltyPoints >= 10000 && this._tier === 'standard') {
            this._tier = 'gold';
        }
    }
}
 
// ============================================
// CROSS-AGGREGATE COORDINATION via Events
// ============================================
 
// When order is confirmed, event is published
class OrderConfirmedEvent {
    constructor(
        readonly orderId: string,
        readonly customerId: string,
        readonly items: Array<{productId: string; quantity: number}>,
        readonly totalAmount: Money,
        readonly pointsToAward: number
    ) {}
}
 
// Event handler updates customer aggregate (eventually consistent)
class CustomerLoyaltyHandler {
    constructor(private readonly customerRepo: CustomerRepository) {}
    
    async handle(event: OrderConfirmedEvent): Promise<void> {
        const customer = await this.customerRepo.findById(event.customerId);
        customer.addLoyaltyPoints(event.pointsToAward, event.orderId);
        await this.customerRepo.save(customer);
    }
}
 
// Event handler updates inventory (eventually consistent)
class InventoryReservationHandler {
    constructor(private readonly productRepo: ProductRepository) {}
    
    async handle(event: OrderConfirmedEvent): Promise<void> {
        for (const item of event.items) {
            const product = await this.productRepo.findById(item.productId);
            product.reserveStock(item.quantity);
            await this.productRepo.save(product);
        }
    }
}

Cross-Aggregate Coordination Patterns

When operations span multiple aggregates, you need coordination strategies. Here are the primary patterns, from simplest to most complex:

Coordination Strategies

•Domain Events (Fire and Forget) — Aggregate publishes event, handlers react. Simple but no guarantee of completion.
•Process Manager / Saga — Coordinates multi-step process, tracks state, handles failures with compensation.
•Choreography — Aggregates react to each other's events without central coordinator. Decentralized but can be hard to trace.
•Two-Phase Commit — All-or-nothing across services. Rarely used due to availability impact.

Pattern 1: Domain Events (Most Common)

The simplest approach: one aggregate makes its change, publishes an event, and other aggregates react.

Domain Events Coordination
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// Step 1: Order confirms and publishes event
class OrderApplicationService {
    constructor(
        private readonly orderRepo: OrderRepository,
        private readonly eventPublisher: DomainEventPublisher
    ) {}
    
    async confirmOrder(orderId: string): Promise<void> {
        const order = await this.orderRepo.findById(orderId);
        
        order.confirm();  // This adds OrderConfirmedEvent to order's events
        
        await this.orderRepo.save(order);  // Persists order
        
        // Publish events after successful persistence
        for (const event of order.getDomainEvents()) {
            await this.eventPublisher.publish(event);
        }
        order.clearDomainEvents();
    }
}
 
// Step 2: Handlers react to event (eventually consistent)
class InventoryEventHandler {
    async handleOrderConfirmed(event: OrderConfirmedEvent): Promise<void> {
        for (const item of event.items) {
            const product = await this.productRepo.findById(item.productId);
            product.reserveStock(item.quantity);
            await this.productRepo.save(product);
        }
    }
}
 
class CustomerEventHandler {
    async handleOrderConfirmed(event: OrderConfirmedEvent): Promise<void> {
        const customer = await this.customerRepo.findById(event.customerId);
        customer.addLoyaltyPoints(event.pointsToAward);
        await this.customerRepo.save(customer);
    }
}
 
class NotificationEventHandler {
    async handleOrderConfirmed(event: OrderConfirmedEvent): Promise<void> {
        await this.emailService.sendOrderConfirmation(
            event.customerId,
            event.orderId,
            event.totalAmount
        );
    }
}

Pattern 2: Saga / Process Manager

For complex multi-step processes that need coordination and failure handling:

Saga Pattern for Order Processing
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
// Saga tracks the state of a multi-aggregate process
type OrderSagaState = 
    | 'started'
    | 'payment_authorized'
    | 'inventory_reserved'
    | 'completed'
    | 'compensating'
    | 'failed';
 
class OrderProcessingSaga {
    private _state: OrderSagaState = 'started';
    private _paymentId: string | null = null;
    private _reservationId: string | null = null;
    
    constructor(
        private readonly orderId: string,
        private readonly customerId: string,
        private readonly items: OrderItemDTO[]
    ) {}
    
    get state(): OrderSagaState { return this._state; }
    
    // Each step transitions state and returns next action
    onPaymentAuthorized(paymentId: string): SagaAction {
        if (this._state !== 'started') {
            throw new Error(`Invalid state transition from ${this._state}`);
        }
        
        this._paymentId = paymentId;
        this._state = 'payment_authorized';
        
        // Next step: reserve inventory
        return {
            type: 'reserve_inventory',
            orderId: this.orderId,
            items: this.items
        };
    }
    
    onInventoryReserved(reservationId: string): SagaAction {
        if (this._state !== 'payment_authorized') {
            throw new Error(`Invalid state transition from ${this._state}`);
        }
        
        this._reservationId = reservationId;
        this._state = 'completed';
        
        // Final step: confirm order
        return {
            type: 'confirm_order',
            orderId: this.orderId
        };
    }
    
    // Handle failures with compensation
    onInventoryReservationFailed(reason: string): SagaAction {
        if (this._state !== 'payment_authorized') {
            throw new Error(`Invalid state transition from ${this._state}`);
        }
        
        this._state = 'compensating';
        
        // Compensate: release payment authorization
        return {
            type: 'release_payment',
            paymentId: this._paymentId!,
            reason: `Inventory unavailable: ${reason}`
        };
    }
    
    onPaymentReleased(): SagaAction {
        this._state = 'failed';
        
        return {
            type: 'fail_order',
            orderId: this.orderId,
            reason: 'Inventory unavailable'
        };
    }
}
 
// Saga Orchestrator coordinates the process
class OrderSagaOrchestrator {
    constructor(
        private readonly sagaRepo: SagaRepository,
        private readonly paymentService: PaymentService,
        private readonly inventoryService: InventoryService,
        private readonly orderService: OrderService
    ) {}
    
    async startSaga(order: OrderDTO): Promise<void> {
        const saga = new OrderProcessingSaga(
            order.orderId,
            order.customerId,
            order.items
        );
        
        await this.sagaRepo.save(saga);
        
        // Start with payment authorization
        await this.paymentService.authorizePayment(
            order.orderId,
            order.totalAmount
        );
    }
    
    async handlePaymentAuthorized(
        orderId: string, 
        paymentId: string
    ): Promise<void> {
        const saga = await this.sagaRepo.findByOrderId(orderId);
        const action = saga.onPaymentAuthorized(paymentId);
        await this.sagaRepo.save(saga);
        
        await this.executeAction(action);
    }
    
    async handleInventoryReserved(
        orderId: string,
        reservationId: string
    ): Promise<void> {
        const saga = await this.sagaRepo.findByOrderId(orderId);
        const action = saga.onInventoryReserved(reservationId);
        await this.sagaRepo.save(saga);
        
        await this.executeAction(action);
    }
    
    async handleInventoryReservationFailed(
        orderId: string,
        reason: string
    ): Promise<void> {
        const saga = await this.sagaRepo.findByOrderId(orderId);
        const action = saga.onInventoryReservationFailed(reason);
        await this.sagaRepo.save(saga);
        
        await this.executeAction(action);
    }
    
    private async executeAction(action: SagaAction): Promise<void> {
        switch (action.type) {
            case 'reserve_inventory':
                await this.inventoryService.reserveInventory(
                    action.orderId, 
                    action.items
                );
                break;
            case 'confirm_order':
                await this.orderService.confirmOrder(action.orderId);
                break;
            case 'release_payment':
                await this.paymentService.releaseAuthorization(
                    action.paymentId,
                    action.reason
                );
                break;
            case 'fail_order':
                await this.orderService.failOrder(
                    action.orderId,
                    action.reason
                );
                break;
        }
    }
}

Saga vs Domain Events

Use simple domain events when: steps are independent, failure of one doesn't require undoing others, order doesn't matter. Use sagas when: steps must complete in order, failure requires compensation, you need to track the overall process state.

Handling Consistency Conflicts

Even with well-designed boundaries, conflicts can occur. Two users might try to modify the same aggregate simultaneously, or eventual consistency might lead to temporary inconsistencies. Here are strategies to handle these situations:

Conflict Resolution Strategies

•Optimistic Concurrency — Each aggregate has a version number. Updates must include the expected version; conflicts are detected and retried.
•Pessimistic Locking — Lock the aggregate before modification. Simpler but reduces throughput.
•Last Write Wins — Accept the most recent change. Acceptable when conflicts are rare and data isn't critical.
•Merge Strategies — Combine conflicting changes intelligently (e.g., both increments to a counter are applied).
•Compensation — When an inconsistency is detected, take corrective action.

Optimistic Concurrency Control
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
// Aggregate with version for optimistic concurrency
class Order {
    private _version: number = 0;
    
    constructor(
        private readonly _orderId: string,
        private _status: OrderStatus,
        // ... other fields
    ) {}
    
    get version(): number { return this._version; }
    
    confirm(): void {
        if (this._status !== 'draft') {
            throw new Error(`Cannot confirm ${this._status} order`);
        }
        this._status = 'confirmed';
        this._version++;  // Increment on change
    }
    
    _setVersion(version: number): void {
        this._version = version;
    }
}
 
// Repository enforces version check on save
class OrderRepository {
    async save(order: Order): Promise<void> {
        const result = await this.db.query(`
            UPDATE orders 
            SET status = $2, version = version + 1
            WHERE id = $1 AND version = $3
            RETURNING version
        `, [order.orderId, order.status, order.version - 1]);
        
        if (result.rowCount === 0) {
            throw new OptimisticConcurrencyError(
                `Order ${order.orderId} was modified by another process`
            );
        }
    }
}
 
// Application service handles retry
class OrderService {
    async confirmOrderWithRetry(
        orderId: string, 
        maxRetries: number = 3
    ): Promise<void> {
        for (let attempt = 1; attempt <= maxRetries; attempt++) {
            try {
                const order = await this.orderRepo.findById(orderId);
                order.confirm();
                await this.orderRepo.save(order);
                return;  // Success
            } catch (error) {
                if (error instanceof OptimisticConcurrencyError) {
                    if (attempt === maxRetries) {
                        throw new Error(
                            `Failed to confirm order after ${maxRetries} attempts`
                        );
                    }
                    // Wait briefly before retry
                    await this.sleep(100 * attempt);
                    continue;
                }
                throw error;  // Different error, don't retry
            }
        }
    }
    
    private sleep(ms: number): Promise<void> {
        return new Promise(resolve => setTimeout(resolve, ms));
    }
}
 
class OptimisticConcurrencyError extends Error {
    constructor(message: string) {
        super(message);
        this.name = 'OptimisticConcurrencyError';
    }
}

Handling Eventual Consistency Failures

When eventual consistency handlers fail, you need strategies to ensure the system eventually reaches a consistent state:

Eventual Consistency Failure Handling

•Retry with backoff — Failed handlers are retried with exponential backoff. Most transient failures resolve themselves.
•Dead letter queue — Events that fail repeatedly are moved to a dead letter queue for manual investigation.
•Idempotent handlers — Handlers can be safely run multiple times. This allows aggressive retrying.
•Reconciliation jobs — Periodic jobs scan for inconsistencies and correct them.
•Alerts and monitoring — Track consistency metrics and alert when handlers fail repeatedly.

Idempotent Event Handler
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// Idempotent handler - safe to run multiple times
class LoyaltyPointsHandler {
    constructor(
        private readonly customerRepo: CustomerRepository,
        private readonly processedEventsRepo: ProcessedEventsRepository
    ) {}
    
    async handle(event: OrderConfirmedEvent): Promise<void> {
        // Check if already processed (idempotency key)
        const alreadyProcessed = await this.processedEventsRepo.exists(
            event.eventId
        );
        
        if (alreadyProcessed) {
            console.log(`Event ${event.eventId} already processed, skipping`);
            return;
        }
        
        // Process the event
        const customer = await this.customerRepo.findById(event.customerId);
        customer.addLoyaltyPoints(event.pointsToAward, event.orderId);
        await this.customerRepo.save(customer);
        
        // Mark as processed
        await this.processedEventsRepo.markProcessed(event.eventId);
    }
}
 
// Alternative: Idempotency at aggregate level
class Customer {
    private readonly _processedOrders: Set<string> = new Set();
    
    addLoyaltyPoints(points: number, orderId: string): void {
        // Idempotency check at domain level
        if (this._processedOrders.has(orderId)) {
            return;  // Already awarded points for this order
        }
        
        this._loyaltyPoints += points;
        this._processedOrders.add(orderId);
    }
}

Boundary Trade-offs and Guidelines

Aggregate boundary decisions involve fundamental trade-offs. Understanding these helps you make informed choices:

Aggregate Size Trade-offs
Aspect	Larger Aggregates	Smaller Aggregates
Consistency	More invariants enforced immediately	Some invariants require eventual consistency
Concurrency	Higher contention, lower throughput	Lower contention, higher throughput
Loading cost	More data loaded per operation	Less data loaded per operation
Complexity	Simpler invariant enforcement	More complex cross-aggregate coordination
Scaling	Harder to distribute	Easier to distribute across nodes
Transactions	Longer, more locks held	Shorter, fewer locks

Start Small, Grow if Needed

It's easier to combine small aggregates than to split large ones. When unsure, start with smaller aggregates and combine only when you discover that invariants truly require immediate consistency across them.

Practical Guidelines for Boundary Design:

Decision Guidelines

•True invariants require immediate consistency — If rule A absolutely cannot tolerate even momentary violation, the objects involved must be in the same aggregate.
•References between aggregates use IDs — Never embed one aggregate root inside another or hold object references across boundaries.
•Design for the common case — Optimize boundaries for the most frequent operations, not edge cases.
•Accept complexity at the edges — Simple aggregates with complex coordination is often better than complex aggregates.
•Test under load — Boundary decisions should be validated with realistic concurrency testing.
•Evolve boundaries — As you learn more about the domain, refactor boundaries. They're not permanent decisions.

Summary: Consistency Boundaries

We've explored how aggregates define consistency boundaries. Let's consolidate the key points:

Key Takeaways

•One transaction = one aggregate — This rule enables scalability while maintaining immediate consistency where needed.
•Distinguish immediate from eventual — Challenge each 'must be immediate' requirement. Many can tolerate eventual consistency.
•Boundaries based on invariants — Objects sharing invariants that require immediate consistency belong together.
•Event-driven cross-aggregate coordination — Domain events enable loose coupling between aggregates.
•Sagas for complex processes — When operations span aggregates and require coordination, use the saga pattern.
•Optimistic concurrency — Handle conflicts with version numbers and retry logic.
•Idempotent handlers — Eventual consistency handlers must be safe to run multiple times.

What's Next:

In the final page of this module, we'll explore Aggregate Design Rules—the practical guidelines and patterns for designing aggregates that are maintainable, performant, and correctly model your domain.

Page Complete

You now understand how aggregates define consistency boundaries. The aggregate is the unit of immediate consistency; cross-aggregate consistency is achieved eventually through events. This design enables both correctness and scalability—the holy grail of distributed systems.