Aggregate Event Sourcing Suitability Assessment Prompt

This prompt is designed for domain architects and senior engineers who need to evaluate a single aggregate's suitability for event sourcing before committing to its operational complexity. The job-to-be-done is not a whole-system decision, but a focused, evidence-backed recommendation on one aggregate at a time. The prompt forces explicit reasoning across four dimensions—audit and compliance requirements, performance and scalability needs, implementation complexity, and team capability—producing a scored output that can feed directly into an Architecture Decision Record (ADR). Use it when the team is debating event sourcing for a specific aggregate, when a compliance requirement demands full audit trails, or when an existing state-based aggregate is struggling with history reconstruction or temporal queries.

Do not use this prompt for whole-system event sourcing decisions without first assessing individual aggregates. Aggregate-level suitability varies significantly within the same bounded context; an aggregate that manages financial transactions may score high on audit needs, while a neighboring aggregate handling user preferences may score low on every dimension. The prompt is also inappropriate when the team has no prior exposure to event sourcing concepts—it assumes the reader understands terms like event store, projection, and causal consistency. If the aggregate is trivial (fewer than three state transitions in its lifecycle), skip the assessment entirely; the overhead of event sourcing will not be justified. For regulated domains such as healthcare or finance, the prompt's output should be reviewed by a compliance officer before finalizing the ADR, particularly when audit trail immutability has legal implications.

Before running the prompt, gather the aggregate's current design: its invariants, state transitions, read and write patterns, concurrency model, and any existing compliance requirements. The prompt template includes placeholders for these inputs. After receiving the scored recommendation, validate the output by checking whether the trade-off documentation addresses each of the four dimensions with concrete evidence from your context. If the model recommends event sourcing but fails to identify at least two operational risks (such as event schema evolution or projection rebuild time), treat the assessment as incomplete and re-run with tighter constraints. The next step is to take the scored output and trade-off summary into your ADR template, adding any team-specific context the model could not have known, such as upcoming hiring plans or platform migrations that affect the complexity dimension.

This prompt template is designed to be pasted directly into your AI system. It forces the model to act as a domain-driven design architect and produce a rigorous, structured assessment rather than a conversational opinion. The output is a JSON object you can parse, store in an architecture decision record, or feed into a downstream review pipeline. Before using it, gather the required context: the aggregate's name, its invariants, the domain's audit and consistency requirements, the team's experience with event sourcing, and any performance or complexity constraints. The more specific your inputs, the less the model will need to guess—and guessing produces unreliable scores.

textCopy
You are a domain-driven design architect evaluating whether a specific aggregate should use event sourcing. Your output must be a single JSON object with no additional text.

## INPUT
- Aggregate Name: [AGGREGATE_NAME]
- Domain Context: [DOMAIN_DESCRIPTION]
- Invariants and Business Rules: [INVARIANTS]
- Audit and History Requirements: [AUDIT_REQUIREMENTS]
- Consistency Requirements (immediate vs eventual): [CONSISTENCY_REQUIREMENTS]
- Performance and Throughput Constraints: [PERFORMANCE_CONSTRAINTS]
- Team Event Sourcing Experience: [TEAM_EXPERIENCE]
- Existing Infrastructure and Tooling: [INFRASTRUCTURE_CONTEXT]
- Regulatory or Compliance Constraints: [COMPLIANCE_CONSTRAINTS]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "aggregate_name": "string",
  "suitability_score": number (0-100),
  "recommendation": "Recommended" | "Conditional" | "Not Recommended",
  "dimension_scores": {
    "audit_and_history_fit": number (0-100),
    "consistency_flexibility": number (0-100),
    "performance_impact": number (0-100, higher means less negative impact),
    "complexity_burden": number (0-100, higher means lower burden),
    "team_readiness": number (0-100),
    "infrastructure_fit": number (0-100),
    "compliance_alignment": number (0-100)
  },
  "rationale": "string (2-4 sentences explaining the overall score)",
  "key_tradeoffs": ["string", "string", "string"],
  "risks_and_mitigations": [
    {"risk": "string", "severity": "High" | "Medium" | "Low", "mitigation": "string"}
  ],
  "alternatives_considered": [
    {"pattern": "string", "fit_assessment": "string"}
  ],
  "implementation_notes": "string (practical guidance if event sourcing is adopted)",
  "decision_triggers": ["string (conditions that would change the recommendation)"]
}

## CONSTRAINTS
- Score each dimension independently before calculating the overall suitability_score. The overall score is a weighted average, not a gut feel.
- If audit requirements are mandatory and strict, audit_and_history_fit must be at least 80.
- If the team has no event sourcing experience, team_readiness must not exceed 30.
- If consistency requirements demand immediate consistency for all operations, consistency_flexibility must not exceed 20.
- Every risk must have a concrete mitigation, not a generic statement.
- Do not recommend event sourcing if the complexity_burden score is below 40 and the aggregate has fewer than 5 distinct state-changing operations.
- If compliance_constraints include GDPR right-to-erasure requirements, you must address how event immutability conflicts with deletion obligations in the risks_and_mitigations array.

To adapt this prompt, replace each square-bracket placeholder with concrete details about your aggregate. For example, [AGGREGATE_NAME] becomes OrderAggregate and [INVARIANTS] becomes a bullet list like - Order total must equal sum of line items; - An order cannot be shipped before payment is confirmed. If a dimension does not apply, provide a brief note like No specific regulatory constraints rather than leaving the placeholder empty. The model will use these details to calibrate its scores. After receiving the output, validate the JSON structure before accepting the recommendation. If the model returns a score without addressing a constraint you specified, treat that as a failure and re-prompt with the missing constraint emphasized.

This prompt works best with models that have strong reasoning capabilities and can follow multi-constraint instructions. Weaker or smaller models may ignore the scoring constraints or produce malformed JSON. In production, always validate the output against the schema, check that dimension scores are within 0-100, and verify that the recommendation aligns with the dimension scores. If the model recommends event sourcing but scores team_readiness at 15, flag the output for human review. The next section covers how to wire this prompt into an automated assessment pipeline with validation, retries, and logging.

This prompt is designed to be called programmatically as part of a design review gate, not as a one-off chat interaction. The typical integration point is an architecture review pipeline that receives an aggregate specification document, a set of non-functional requirements, and team context metadata. The harness should assemble these inputs into the [AGGREGATE_SPEC], [NFR_CONTEXT], and [TEAM_CONTEXT] placeholders before invoking the model. Because the output is a structured suitability score with trade-off dimensions, the harness must validate the response shape before accepting it as review evidence.

Implement a validation layer that checks the response against the declared [OUTPUT_SCHEMA] before the result enters any decision record. At minimum, confirm that the suitability_score field is an integer between 0 and 100, that each trade-off dimension includes a risk_level enum value, and that the recommendation field matches one of the expected values (recommended, conditional, or not_recommended). If validation fails, retry once with the same inputs and an explicit repair instruction appended to the prompt: 'Your previous response failed schema validation. Return ONLY a valid JSON object matching the output schema.' If the second attempt also fails, log the failure, flag the assessment for human review, and do not auto-approve the aggregate design. For high-risk domains such as finance, healthcare, or safety-critical systems, always require a human architect to confirm the assessment before it becomes part of an ADR.

Model choice matters for this workflow. Use a model with strong reasoning capabilities and reliable structured output support, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may produce plausible-sounding but inconsistent scores across multiple runs. If you are running this assessment across many aggregates in a batch, consider caching the [NFR_CONTEXT] and [TEAM_CONTEXT] portions of the prompt as a reusable prefix to reduce token costs. Log every assessment result with the prompt version, model identifier, timestamp, and validation outcome. This audit trail is essential when the suitability score is used to justify architectural decisions that will be revisited months later. The next step after wiring the harness is to define the evaluation rubric that determines whether the prompt's assessments align with expert architect judgments over time.