Tactical DDD

Implementation patterns within a bounded context. Tactical DDD answers: "How do we structure the domain model?"

Aggregates

An aggregate is a consistency boundary -- a cluster of domain objects that must be transactionally consistent.

Vernon's Four Design Rules

1. Model true invariants in consistency boundaries: Only include elements that MUST be consistent within the same transaction. If two entities don't share an invariant, they belong in separate aggregates.

2. Design small aggregates: ~70% of aggregates contain only a root entity with value-typed properties. Large aggregates create concurrency contention, scalability failures, and memory pressure.

3. Reference other aggregates by identity: Use ProductId not Product. Direct object references create accidental cross-aggregate transactions and prevent independent scaling.

4. Use eventual consistency outside the boundary: Domain events communicate across aggregates. One transaction = one aggregate. If you need to update two aggregates "atomically," reconsider your boundaries.

Aggregate Design Checklist

• Contains only elements sharing true invariants
• Root entity controls all access (no direct child manipulation)
• External references by ID only (no object graphs)
• Small enough for single-transaction performance
• Command produces events (in event-sourced systems) or mutates state (in traditional)
• Business rules validated in command handling, not in persistence layer

Common Aggregate Smells

Smell	Signal	Fix
God Aggregate	>5 entities, frequent concurrency conflicts	Split by invariant analysis
Anemic Aggregate	All logic in services, aggregate = data bag	Move business rules into aggregate methods
Cross-Aggregate Transaction	Two aggregates modified in one DB transaction	Use domain events + eventual consistency
Deep Nesting	Aggregate root -> entity -> entity -> value	Flatten; promote nested entities to own aggregates
Missing Aggregate	Business rules scattered in application services	Identify invariant cluster, create aggregate

Entities

Objects with identity that persists across state changes. An entity is the "same" entity even when all its attributes change (a person who changes name, address, and job is still the same person).

Design rules: Identity is assigned once and never changes | Equality by identity, not attributes | Track lifecycle (created, modified, archived) | Place business rules that depend on identity here

Value Objects

Objects defined by their attributes, not identity. Two value objects with the same attributes are interchangeable.

Design rules:

• Immutable: Never modify; create new instances
• Self-validating: Constructor rejects invalid state. If a Money object exists, it has a valid amount and currency
• Side-effect-free behavior: Methods return new values, don't mutate
• Structural equality: Compare by attributes, not reference

Examples: Money(amount, currency) | Email(address) | DateRange(start, end) | Address(street, city, zip, country) | Temperature(value, unit)

Context sensitivity: Whether something is Entity or Value Object depends on bounded context. Address is a VO in e-commerce (shipping destination) but an Entity in utility billing (service location with lifecycle).

Domain Events

Represent something that happened in the domain. Always past tense.

Naming Convention

Correct (past tense)	Wrong (imperative)
OrderPlaced	PlaceOrder (that's a command)
PaymentReceived	ReceivePayment
UserRegistered	RegisterUser
InventoryReserved	ReserveInventory

Event Design Guidelines

• Self-contained: Include all data needed to understand what happened
• Domain language: Business terms, not technical jargon
• One fact per event: OrderConfirmed not OrderStatusChanged
• No behavior: Events carry data only
• Granularity matters: Too coarse (OrderUpdated) loses meaning; too fine (OrderFieldChanged) is a generic audit log

Event Categories

Domain events (in-process): Within a bounded context, dispatched via mediator. Collected during command handling, dispatched before/after commit.

Integration events (distributed): Cross bounded-context via message brokers. Always asynchronous. Published only after successful persistence. May use different schema than domain events (translated at boundary).

Repositories

One repository per aggregate (not per entity). Interface defined in domain layer, implementation in infrastructure.

Collection-oriented: add/remove/find -- repository tracks changes (Unit of Work pattern). Natural for ORMs.

Persistence-oriented: explicit save/load -- caller manages lifecycle. Natural for document DBs and event-sourced systems.

Rules: Never expose persistence details (SQL, JSON) to domain | Return domain objects, not DTOs | Query methods use domain language (findActiveOrders, not findByStatusEquals)

Domain Services

Stateless operations that span multiple aggregates or don't naturally belong to any single entity.

When to use: Operation involves multiple aggregates | Logic doesn't belong to any entity | Named using ubiquitous language

Danger: Overuse creates anemic domain models. First try to place the behavior on an entity or aggregate. Domain service is the last resort for truly cross-aggregate logic.

Domain Service	Application Service
Domain logic (rules, calculations)	Orchestration (transaction, security, events)
Domain types only	Domain + infrastructure ports
Domain layer	Application layer
TransferFunds, CalculateDiscount	PlaceOrderHandler, RegisterUserUseCase

Anti-Pattern Detection

When analyzing existing code, look for these patterns:

Anti-Pattern	Code Signal	Recommendation
Anemic Domain Model	Entities = data classes, services contain all if logic	Move business rules to entities/aggregates
Primitive Obsession	String email, double amount, int quantity	Create value objects: Email, Money, Quantity
Database-Driven Design	Entities mirror DB tables 1:1, foreign keys as navigation	Model domain first, map to persistence second
Missing Boundaries	Single model used by all features, vocabulary conflicts	Identify contexts via language divergence
Logic in Wrong Layer	Business rules in controllers/handlers	Push down to domain objects
Service Bloat	Service class with 20+ methods	Split by use case, push logic to aggregates
Event as RPC	Event handler returns result that caller depends on	Events are fire-and-forget; use command for request-response