Domain Model Consistency Check Prompt

Domain architects and engineering leads use this prompt to validate that domain models remain consistent across multiple aggregates and bounded contexts before implementation diverges. The job-to-be-done is a structured design-time review that catches conflicting business rules, duplicate concepts, and invariant violations that would otherwise surface as production incidents, integration failures, or contradictory service behavior. This prompt assumes you have documented aggregate definitions, business rules, invariants, and context boundaries—it does not infer these from code or runtime traces.

Use this prompt when teams report conflicting behavior between services, when merging bounded contexts, when conducting a pre-implementation design review for a new feature that spans contexts, or when auditing an existing system for domain model drift. The prompt works best with concrete artifacts: aggregate root definitions, method signatures with preconditions and postconditions, context map diagrams, domain event schemas, and explicit invariant statements. Without these inputs, the model will generate plausible but ungrounded analysis that may miss real conflicts or flag false positives.

Do not use this prompt for runtime data validation, code-level linting, single-aggregate design reviews, or database schema consistency checks. It is not a substitute for integration tests, contract tests, or static analysis tools. The output is a structured consistency report that flags conflicts, duplicates, and invariant violations with severity ratings and remediation guidance—but it requires human review before acting on high-severity findings. For regulated domains, always pair this prompt with a manual architecture review and document the evidence sources used in the analysis.

The following prompt template is designed to be copied directly into your AI workflow. It expects you to provide your domain artifacts—such as aggregate definitions, context maps, domain event schemas, and business rules—in the designated placeholders. The model will analyze these artifacts and produce a structured consistency report that flags conflicting rules, duplicate concepts, and invariant violations that cross aggregate or context boundaries. This report serves as a pre-implementation design review artifact, catching misaligned mental models before they become incompatible code.

textCopy
You are a domain architecture reviewer specializing in Domain-Driven Design consistency analysis. Your task is to examine the provided domain artifacts and produce a structured consistency report.

## INPUT ARTIFACTS

### Aggregate Definitions
[Aggregate definitions with root entities, child entities, value objects, and invariants for each aggregate]

### Bounded Context Map
[Context map showing bounded contexts, their relationships, translation layers, and integration patterns]

### Domain Event Schemas
[Domain event definitions including event names, payloads, producers, consumers, and versioning information]

### Business Rules and Invariants
[Cross-aggregate and cross-context business rules, consistency requirements, and transactional boundaries]

### Ubiquitous Language Glossary
[Canonical terms, definitions, synonyms, and deprecated terms across all contexts]

## OUTPUT SCHEMA

Produce a JSON object with the following structure:

{
  "report_summary": {
    "total_conflicts": <number>,
    "total_duplicates": <number>,
    "total_invariant_violations": <number>,
    "overall_severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
    "review_recommendation": "PROCEED" | "REVIEW_REQUIRED" | "BLOCKED"
  },
  "conflicts": [
    {
      "id": "CONF-<number>",
      "severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
      "description": "<clear description of the conflict>",
      "affected_artifacts": ["<artifact name and location>"],
      "conflicting_rules": ["<rule A>", "<rule B>"],
      "impact": "<what breaks if this conflict is not resolved>",
      "resolution_suggestion": "<actionable recommendation>"
    }
  ],
  "duplicates": [
    {
      "id": "DUP-<number>",
      "severity": "LOW" | "MEDIUM" | "HIGH",
      "concept_name": "<the duplicated concept>",
      "locations": ["<context or aggregate where it appears>"],
      "differences": "<how the definitions diverge>",
      "canonical_source": "<which location should be authoritative>",
      "resolution_suggestion": "<how to consolidate>"
    }
  ],
  "invariant_violations": [
    {
      "id": "INV-<number>",
      "severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
      "invariant": "<the invariant being violated>",
      "owning_aggregate": "<aggregate responsible for the invariant>",
      "violation_path": "<how the invariant can be broken across boundaries>",
      "affected_contexts": ["<context names>"],
      "resolution_suggestion": "<how to protect the invariant>"
    }
  ],
  "terminology_issues": [
    {
      "id": "TERM-<number>",
      "term": "<the ambiguous term>",
      "contexts": ["<contexts where it appears with different meanings>"],
      "meanings": ["<meaning in context A>", "<meaning in context B>"],
      "risk": "<what misunderstanding this causes>",
      "resolution_suggestion": "<disambiguation strategy>"
    }
  ],
  "integration_gaps": [
    {
      "id": "GAP-<number>",
      "severity": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
      "contexts_involved": ["<context A>", "<context B>"],
      "missing_integration": "<what integration pattern or translation is absent>",
      "data_consistency_risk": "<what data becomes stale or inconsistent>",
      "resolution_suggestion": "<recommended integration pattern>"
    }
  ]
}

## CONSTRAINTS

- Only report issues you can trace to specific artifacts provided in the input. Do not invent problems.
- For each finding, cite the specific artifact, rule, or definition that supports the finding.
- If no issues are found in a category, return an empty array for that category.
- Severity ratings: LOW (cosmetic or documentation-only), MEDIUM (operational friction but no data corruption), HIGH (potential data inconsistency or incorrect behavior), CRITICAL (guaranteed data corruption or system failure).
- If the input artifacts are insufficient to complete the analysis, return a partial report and include a `limitations` array explaining what is missing.

## EXAMPLES

### Example Conflict
{
  "id": "CONF-001",
  "severity": "HIGH",
  "description": "Order aggregate requires PaymentConfirmed event before shipping, but Shipping context ships on OrderPlaced event without checking payment status.",
  "affected_artifacts": ["Order aggregate invariants", "Shipping context event handler"],
  "conflicting_rules": ["Orders must not ship before payment confirmation", "Shipping processes all OrderPlaced events immediately"],
  "impact": "Unpaid orders can be shipped, causing revenue loss and reconciliation overhead.",
  "resolution_suggestion": "Add PaymentConfirmed event as a precondition in the Shipping context's ship-order policy, or introduce a Saga that coordinates the full order-to-shipment flow."
}

### Example Duplicate
{
  "id": "DUP-001",
  "severity": "MEDIUM",
  "concept_name": "Customer Credit Limit",
  "locations": ["Billing context - Customer aggregate", "Ordering context - Buyer aggregate"],
  "differences": "Billing calculates credit limit from payment history; Ordering stores a static credit_limit field that is manually updated.",
  "canonical_source": "Billing context - Customer aggregate",
  "resolution_suggestion": "Remove the static credit_limit field from Ordering. Ordering should query Billing via an Anti-Corruption Layer or consume CreditLimitUpdated events."
}

## RISK LEVEL
[RISK_LEVEL: LOW | MEDIUM | HIGH | CRITICAL]

If RISK_LEVEL is HIGH or CRITICAL, flag all findings for human review and include a `human_review_required` boolean in the report_summary set to true.

To adapt this prompt for your domain, replace each square-bracket placeholder with your actual artifacts. The [Aggregate definitions] placeholder should contain your aggregate root definitions, child entities, value objects, and the invariants each aggregate enforces. The [Bounded Context Map] placeholder expects your context map showing relationships, translation layers, and integration patterns between contexts. For [Domain Event Schemas], include event names, payload structures, producer contexts, consumer contexts, and any versioning information. The [Business Rules and Invariants] placeholder should capture cross-aggregate and cross-context rules that span boundaries. The [Ubiquitous Language Glossary] should list canonical terms alongside any known synonyms or deprecated terms. Finally, set [RISK_LEVEL] to reflect the operational risk of your domain—use HIGH or CRITICAL for financial, healthcare, or safety-critical systems to ensure findings are flagged for mandatory human review.

Before integrating this prompt into a production pipeline, validate the output against the expected JSON schema. A common failure mode is the model producing findings without citing specific artifacts—if the affected_artifacts or locations fields are empty or vague, treat the finding as low-confidence and flag it for human verification. Another failure mode is severity inflation, where the model marks every issue as HIGH or CRITICAL. Calibrate severity by spot-checking a sample of findings against your team's actual operational experience. For high-risk domains, always require a domain expert to review the consistency report before acting on its recommendations. The prompt is a design review accelerator, not a replacement for architectural judgment.

This prompt is designed to be integrated into a structured design review pipeline, not used as a one-off chat interaction. The implementation harness should treat the prompt as a stateless function that accepts a structured domain model specification and returns a structured consistency report. Because the output drives architectural decisions, the harness must enforce validation, handle model non-determinism, and route findings to the right human reviewers. The prompt is not a replacement for a domain architect's judgment; it is a consistency scanner that surfaces conflicts a human might miss when reviewing large models across multiple aggregates and bounded contexts.

Wire the prompt into an application by building a pre-processing layer that assembles the [DOMAIN_MODEL_SPEC] from source artifacts: event schemas, aggregate definitions, context maps, and ubiquitous language glossaries. The spec should be a structured JSON or YAML document containing aggregates, their invariants, entities, value objects, domain events, and cross-context references. After the model responds, a post-processing validator must parse the output against the [OUTPUT_SCHEMA]—a JSON schema defining the consistency report structure with fields for conflicting_rules, duplicate_concepts, invariant_violations, and boundary_misalignments. If parsing fails, retry once with a repair prompt that includes the raw output and the schema. If the second attempt fails, log the failure and escalate to a human reviewer. For high-risk domains (finance, healthcare, safety-critical systems), always require human approval before accepting any flagged inconsistency as a confirmed issue. Log every run with the model version, input spec hash, output report, and reviewer decision for auditability.

Model choice matters here. Use a model with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) because consistency checking requires cross-referencing rules across a large context window. Do not use a small or fast model for this task; false negatives (missed inconsistencies) are more dangerous than false positives. If the domain model is too large for a single context window, split it by bounded context cluster and run the prompt per cluster, then run a cross-cluster consistency pass that takes the per-cluster reports as input. Implement a confidence threshold: if the model expresses low confidence or flags an issue with hedging language, route that finding to a separate review queue rather than treating it as a confirmed defect. Avoid wiring this prompt into a fully automated CI/CD pipeline that blocks merges; the output is advisory and requires architectural judgment to interpret trade-offs between consistency and pragmatic coupling.

For teams using event-driven architectures, integrate this prompt after domain event schema changes. When a new event version is proposed, run the consistency check against the updated model to catch invariant violations before the event reaches production. Store the consistency report alongside the event schema in the schema registry. For teams practicing continuous architecture review, schedule this prompt to run weekly against the living domain model documentation, surfacing drift between documented and implemented models. The next step after receiving a consistency report is to triage findings: conflicting rules require a design decision meeting, duplicate concepts need glossary reconciliation, and invariant violations demand aggregate redesign. Do not treat all findings as equal priority; the harness should include a severity classifier that routes critical violations to the architecture team and low-severity notes to the domain model backlog.