Bounded Context Boundary Review Prompt Template

Domain architects and engineering teams use this prompt to audit bounded context definitions before they become incompatible implementations. The primary job-to-be-done is to surface misaligned mental models, hidden coupling, and cohesion gaps while the design is still cheap to change. This review is most effective when a team proposes a new bounded context, when an existing context boundary is under debate during a refactoring discussion, or during a formal architecture review cycle before committing to service decomposition. The prompt assumes you have three concrete inputs: a written context definition describing the responsibilities and invariants of the proposed boundary, a context map or integration diagram showing how this context relates to its neighbors, and at least one stakeholder who can articulate the business capabilities the context is meant to serve. Without these inputs, the prompt will produce speculative assessments that add noise rather than clarity.

The prompt produces a structured boundary assessment with four key deliverables: a cohesion score indicating how well the context's responsibilities cluster together, a coupling risk analysis identifying integration points that could create distributed monolith problems, misalignment flags that highlight contradictions between the written definition and the stakeholder's business capability description, and a set of concrete boundary adjustment recommendations. Each finding is grounded in evidence from the provided artifacts, not in generic DDD heuristics. The evaluation checks for specific failure patterns such as context leakage where one context's logic appears in another's definition, missing integration points where the context map shows no relationship but business capabilities require one, and responsibility overlap where two contexts claim ownership of the same business function. These checks are designed to catch the most common causes of bounded context failure before implementation begins.

Do not use this prompt for runtime performance analysis, infrastructure topology review, or code-level refactoring decisions. Those require different evaluation frameworks with different inputs and success criteria. This prompt also should not replace collaborative domain discovery workshops such as EventStorming sessions; it is a review tool that validates and stress-tests the output of those workshops, not a substitute for the collaborative design process itself. If you lack a written context definition or cannot articulate the business capabilities the context serves, start with the Bounded Context Discovery from Legacy Code prompt or the Core Domain Identification and Prioritization prompt to establish those foundations before running this boundary review. After completing the review, use the findings as input to the Bounded Context Integration Pattern Selection prompt to choose appropriate integration strategies for the identified coupling points, and feed any misalignment flags back into your ubiquitous language refinement process.

This template is designed to be dropped into a prompt assembly pipeline, a chat interface, or an automated review harness. Every placeholder in square brackets represents a variable your application should populate before sending the request. Do not leave placeholders unresolved in production — missing context produces unreliable boundary assessments. The template expects structured input describing the bounded context under review, the surrounding landscape, and the output format you need.

textCopy
You are a domain architecture reviewer specializing in Domain-Driven Design bounded context analysis. Your task is to evaluate a bounded context boundary definition and produce a structured assessment.

## INPUT
[BOUNDED_CONTEXT_DEFINITION]

## SURROUNDING CONTEXT LANDSCAPE
[SURROUNDING_CONTEXTS]

## BUSINESS CAPABILITY MAP
[CAPABILITY_MAP]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "context_name": "string",
  "cohesion_score": number (1-10),
  "cohesion_rationale": "string",
  "coupling_risks": [
    {
      "target_context": "string",
      "risk_type": "data_leakage | behavioral_coupling | temporal_coupling | integration_overlap",
      "severity": "high | medium | low",
      "description": "string",
      "evidence": "string"
    }
  ],
  "misalignment_flags": [
    {
      "type": "ubiquitous_language_conflict | responsibility_overlap | missing_integration_point | anemic_boundary | wrong_decomposition_axis",
      "description": "string",
      "recommendation": "string"
    }
  ],
  "integration_points": [
    {
      "target_context": "string",
      "pattern": "acl | open_host | published_language | partnership | customer_supplier | conformist | separate_ways",
      "current_state": "defined | missing | underspecified",
      "gap_description": "string"
    }
  ],
  "boundary_clarity": "clear | fuzzy | contested",
  "refactoring_signals": ["string"],
  "overall_assessment": "string",
  "review_confidence": number (0.0-1.0)
}

## CONSTRAINTS
- Base every finding on evidence from the provided definitions and landscape.
- If evidence is insufficient for a finding, set review_confidence lower and note gaps in overall_assessment.
- Do not invent context names, integration points, or risks not supported by the input.
- Flag missing integration points explicitly rather than assuming they don't exist.
- For cohesion scoring, consider: Does this context own a single, coherent business capability? Do its aggregates share a consistent ubiquitous language? Would splitting or merging improve clarity?
- For coupling risks, identify where this context depends on or leaks into other contexts beyond its defined integration points.

## RISK LEVEL
[HIGH_RISK_DOMAINS]

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Adaptation guidance: Replace [BOUNDED_CONTEXT_DEFINITION] with the context name, its core responsibility, key aggregates, domain events it publishes or consumes, and its explicit integration contracts. [SURROUNDING_CONTEXTS] should list adjacent contexts with their responsibilities and known relationships. [CAPABILITY_MAP] provides the business capability landscape so the model can detect responsibility overlap. [HIGH_RISK_DOMAINS] should flag contexts involving payments, identity, compliance, or safety — the model will apply stricter scrutiny. [FEW_SHOT_EXAMPLES] is optional but recommended: include one well-bounded context example and one with known boundary problems to calibrate the model's judgment. If your application cannot provide all inputs, reduce the review_confidence expectation in your eval criteria and consider routing incomplete cases for human review before acting on the assessment.

This prompt is designed to run as part of a design review pipeline, not as a one-off chat interaction. The typical integration point is a pull request or architecture review checklist where a domain architect or tech lead submits a bounded context definition document. The application layer should collect the required inputs—context name, domain description, aggregate list, integration points, and ubiquitous language samples—and assemble them into the [INPUT] block before calling the model. Because the output is a structured boundary assessment with cohesion scores, coupling risks, and misalignment flags, the harness must validate that the model returns the expected schema before surfacing results to the reviewer.

Schema validation is the first post-generation step. Define a strict output contract: a JSON object with required fields including cohesion_score (number 0-1), coupling_risks (array of objects with source_context, target_context, risk_type, severity, and rationale), misalignment_flags (array of objects with term, context_a_meaning, context_b_meaning, and impact), and missing_integration_points (array of strings). If the model output fails schema validation, retry once with the validation error injected into the [CONSTRAINTS] block. After two failures, escalate to a human reviewer with the raw output and validation errors attached. Model choice matters: use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and enable JSON mode or structured output features where available. For teams running this prompt against multiple contexts in batch, implement rate limiting and queue the reviews with a concurrency cap of 3-5 parallel calls to avoid API throttling.

Logging and traceability are essential because boundary decisions affect team structures and service contracts. Log every review run with: the input context definition, the full model output, the validation result (pass/fail), any retry attempts, and the final reviewer decision. Store these in a review registry that can be referenced in Architecture Decision Records. Human review gate is mandatory for high-risk findings: any coupling risk rated critical or any misalignment flag with impact: high should block automated acceptance and require a domain architect to confirm or dismiss the finding. The harness should present these flagged items in a review UI with accept/dismiss/comment actions, and record the reviewer's decision alongside the model output. Do not treat this prompt as an automated gate that replaces human judgment—it is a structured analysis tool that accelerates review by surfacing risks a human might miss, but the final boundary decision always belongs to the team that owns the contexts.