{
    "slug": "aggregate_design",
    "term": "Aggregate Design Heuristics",
    "category": "architecture",
    "difficulty": "advanced",
    "short": "Rules for sizing aggregates correctly — small aggregates with single-entity transactions, referencing other aggregates by ID, and designing boundaries around invariants not convenience.",
    "long": "DDD aggregates enforce consistency boundaries. Key heuristics (Vaughn Vernon): (1) Design small aggregates — large aggregates cause contention; (2) Reference other aggregates by ID, not reference — prevents loading unnecessary objects; (3) One transaction per aggregate — if a use case modifies two aggregates, it probably needs eventual consistency; (4) Design around business invariants — what rules must always be true within this boundary?; (5) Accept eventual consistency between aggregates — use domain events to propagate changes.",
    "aliases": [
        "aggregate sizing",
        "aggregate boundaries",
        "DDD aggregates",
        "Vaughn Vernon"
    ],
    "tags": [
        "architecture",
        "ddd",
        "design"
    ],
    "misconception": "Larger aggregates are safer because they enforce more invariants in one transaction — large aggregates cause write contention, lock timeouts, and performance problems; most aggregates should be 2-5 entities.",
    "why_it_matters": "An Order aggregate that includes the Customer, all LineItems, the Product catalogue, and Inventory will lock all these records on every order placement — a correctly sized aggregate locks only the Order and its lines.",
    "common_mistakes": [
        "Aggregates sized for convenience (everything in one place) not invariants.",
        "Object references between aggregates — use IDs; cross-aggregate references cause loading chains.",
        "Two aggregates in one transaction — design for eventual consistency between them.",
        "Customer as part of Order aggregate — Customer has its own life cycle and invariants; reference by ID."
    ],
    "when_to_use": [
        "Enforcing invariants that span multiple objects — an Order and its OrderLines must be consistent together.",
        "Transactional consistency boundaries in a domain model — one aggregate per transaction.",
        "Domain-driven design contexts where you need a clear root that controls access to child entities.",
        "Preventing direct manipulation of child entities from outside the aggregate boundary."
    ],
    "avoid_when": [
        "The aggregate is too large — loading an entire order with all line items and history to change one field is wasteful.",
        "Aggregates reference other aggregates by object rather than by ID — this creates tight coupling across boundaries.",
        "Business rules span multiple aggregates — this is a sign the boundary is wrong, not that the rule should be in both."
    ],
    "related": [
        "ddd_aggregates",
        "domain_events",
        "bounded_context",
        "event_sourcing"
    ],
    "prerequisites": [
        "domain_driven_design",
        "bounded_context",
        "db_transactions"
    ],
    "refs": [
        "https://www.dddcommunity.org/library/vernon_2011/"
    ],
    "bad_code": "// Oversized aggregate — locks everything:\nclass Order {\n    private Customer $customer;    // Full Customer object\n    private Product[] $catalogue;  // Full product catalogue\n    private Inventory $inventory;  // All inventory\n    // Placing one order locks: customer table, product table, inventory\n    // All concurrent orders for any product contend on inventory\n}",
    "good_code": "// Small aggregate — reference by ID:\nclass Order {\n    private OrderId $id;\n    private CustomerId $customerId;  // ID reference only\n    private OrderLine[] $lines;      // Only own entities\n    private Money $total;\n    // Invariant: total must equal sum of line amounts\n    // Only locks: this order's rows — no customer/product contention\n}\n// When Order is placed, domain event notifies Inventory aggregate separately",
    "quick_fix": "Define transaction boundaries at the aggregate root — only the root entity should be modified and persisted in a single transaction; reference other aggregates by ID not by object",
    "severity": "medium",
    "effort": "high",
    "created": "2026-03-16",
    "updated": "2026-06-10",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/aggregate_design",
        "html_url": "https://codeclaritylab.com/glossary/aggregate_design",
        "json_url": "https://codeclaritylab.com/glossary/aggregate_design.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[Aggregate Design Heuristics](https://codeclaritylab.com/glossary/aggregate_design) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/aggregate_design"
            }
        }
    }
}