Aggregate Root Design Validation Prompt

This prompt is for a domain architect or senior engineer who has drafted aggregate boundaries and root entity selections for a specific bounded context and needs a structured design critique before those decisions are locked into code. The job-to-be-done is not to generate a design from scratch, but to stress-test an existing design proposal against DDD tactical patterns: size, invariants, reference patterns, concurrency boundaries, and cascade depth. The reader should bring a concrete aggregate design—a diagram, a list of entities and value objects, or a written description of transactional boundaries—and use this prompt to surface risks that are easy to miss during whiteboard sessions, such as an aggregate that protects invariants but creates a single point of contention under concurrent writes.

The prompt requires the user to provide a description of the proposed aggregate, including its root, internal entities, value objects, invariants, and references to other aggregates. It works best when the input includes the specific business rules the aggregate must enforce, because the critique can then check whether the boundary is wide enough to protect those rules without being so wide that it drags in unrelated data. Do not use this prompt when you have not yet identified candidate aggregates—start with a Bounded Context Boundary Review or a Domain Model Consistency Check instead. Do not use it when the design is already implemented and you need a code-level review; this prompt operates at the design model level, not the code model level.

The output is a structured critique, not a binary pass/fail. Expect findings organized around size and cohesion, invariant protection, reference patterns (by identity vs. direct object references), concurrency and transaction boundaries, and cascade depth for persistence operations. The prompt includes checks for anemic aggregates—where the root entity is a property bag with no behavior methods—and will flag when business logic has leaked into domain services or application services. After receiving the critique, the reader should decide which findings to act on and which represent acceptable trade-offs given their specific consistency, performance, and team structure constraints. Do not treat every finding as a mandatory change; the prompt identifies risks, but the team owns the trade-off decisions.

This prompt template is designed to produce a structured design critique of an aggregate root. It evaluates boundary size, invariant enforcement, reference patterns, concurrency implications, and common anti-patterns such as anemic aggregates or excessive cascade depth. The template is ready to copy into your AI harness, IDE, or evaluation pipeline. Replace each square-bracket placeholder with the specific context for your review session before sending the prompt to the model.

textCopy
You are a domain-driven design architect reviewing an aggregate root definition. Your task is to produce a structured design critique. Do not propose implementation code. Focus on design correctness, consistency boundaries, and transactional integrity.

## INPUT
[Aggregate Root Name]: [AGGREGATE_NAME]
[Bounded Context]: [CONTEXT_NAME]
[Domain Description]: [DOMAIN_DESCRIPTION]
[Aggregate Definition]: [AGGREGATE_DEFINITION]
[Invariants]: [INVARIANT_LIST]
[Related Aggregates]: [RELATED_AGGREGATE_REFERENCES]
[Concurrency Model]: [CONCURRENCY_MODEL]

## CONSTRAINTS
- Evaluate whether the aggregate boundary is correctly sized: too large aggregates cause contention; too small aggregates break invariants.
- Check that every invariant is enforceable within a single transaction.
- Identify any reference to other aggregates by identity only; flag direct object references.
- Flag any cascade depth beyond one level of nested entities.
- Detect anemic aggregate signs: missing behavior methods, logic living in domain services instead of the aggregate root.
- Assess concurrency conflict probability given the stated model.
- If the aggregate uses event sourcing, evaluate event granularity and snapshot strategy.

## OUTPUT_SCHEMA
Return a JSON object with the following structure:
{
  "aggregate_name": "string",
  "overall_assessment": "APPROVED | NEEDS_REVISION | REJECTED",
  "boundary_size": {
    "assessment": "TOO_LARGE | APPROPRIATE | TOO_SMALL",
    "rationale": "string",
    "entity_count": "number",
    "cascade_depth": "number"
  },
  "invariant_analysis": [
    {
      "invariant": "string",
      "enforceable_in_transaction": "boolean",
      "issue": "string or null"
    }
  ],
  "reference_patterns": [
    {
      "referenced_aggregate": "string",
      "reference_type": "IDENTITY_REFERENCE | DIRECT_OBJECT_REFERENCE",
      "risk": "string"
    }
  ],
  "anemic_domain_signals": ["string"],
  "concurrency_assessment": {
    "conflict_probability": "LOW | MEDIUM | HIGH",
    "rationale": "string",
    "mitigation_suggestions": ["string"]
  },
  "event_sourcing_notes": "string or null",
  "refactoring_recommendations": ["string"],
  "confidence": "HIGH | MEDIUM | LOW"
}

## RISK_LEVEL
[HIGH | MEDIUM | LOW]

## EXAMPLES
[OPTIONAL_FEW_SHOT_EXAMPLES]

To adapt this template, start by filling in the required inputs with concrete domain details. If you have known good or bad aggregate designs from your system, add them to the [OPTIONAL_FEW_SHOT_EXAMPLES] placeholder to calibrate the model's judgment. For high-risk domains such as financial ledgers or healthcare records, set [RISK_LEVEL] to HIGH and route the model's output through a human review step before accepting any refactoring recommendations. After the model returns the JSON output, validate it against the schema before surfacing it in your design review tool or architecture decision log. If the confidence field returns LOW, treat the critique as advisory only and escalate to a senior architect for manual review.

This prompt is designed to be integrated into a design review pipeline, not just used as a one-off chat. The typical integration point is a pull request or architecture decision record (ADR) workflow where a team member submits an aggregate design for automated critique before human review. The prompt expects a structured input containing the aggregate name, its properties, methods, invariants, and references to other aggregates. You should build a thin application layer that collects this information from the engineer—either through a form, a structured markdown template, or by parsing a domain model diagram—and then assembles the prompt with the collected values injected into the [AGGREGATE_DESIGN] placeholder.

Validation is critical before the model response reaches a human reviewer. Implement a post-processing step that parses the model's output and checks for the presence of all required sections: size assessment, invariant analysis, reference pattern critique, concurrency implications, and anemic aggregate detection. If any section is missing or the output does not conform to the expected JSON schema, retry the prompt once with a stronger constraint instruction. If the retry also fails, flag the review as 'incomplete' and surface the raw output to the human reviewer with a warning. For high-risk domains like finance or healthcare, always require a human to approve or reject the model's findings before they are recorded in the ADR.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, as aggregate designs can be verbose. GPT-4o or Claude 3.5 Sonnet are good defaults. Avoid smaller or faster models for this task unless you have fine-tuned them on domain-driven design critique examples. Log every prompt and response pair, including the model version, timestamp, and the human reviewer's final disposition (accepted, rejected, or modified). This log becomes your evaluation dataset for regression testing when you change the prompt or upgrade the model. Do not wire this prompt directly into an automated merge gate; the output is advisory and requires human judgment to weigh trade-offs like consistency versus performance.