Bounded Context Coupling Assessment Prompt

Domain architects and platform engineers use this prompt to assess coupling between bounded contexts before implementation decisions create irreversible entanglement. The primary job-to-be-done is generating a structured coupling report that identifies relationship types, evaluates translation layer adequacy, detects domain language leakage, and flags context map violations. This is a design-time analysis tool, not a runtime monitoring solution. The ideal user has documented context definitions, integration points, and domain terminology available as input—this prompt cannot invent your domain model for you.

Use this prompt during architecture review sessions, pre-implementation design gates, and modernization planning when you need evidence that your bounded contexts are genuinely independent rather than accidentally coupled through shared language, data contracts, or implicit assumptions. It is particularly valuable when multiple teams own different contexts and you need an objective assessment of whether their integration patterns respect DDD principles. The prompt assumes you have already done the hard work of identifying your bounded contexts and mapping their relationships; it validates those decisions rather than making them from scratch.

This prompt does not replace static analysis of code-level dependencies. It operates at the conceptual and design level, examining how contexts relate through language, contracts, and integration patterns. For implementation-level coupling analysis, pair it with the Component Boundary Leakage Detection Prompt to catch code-level violations or the Dependency Structure Matrix Generation Prompt to visualize actual import dependencies. Do not use this prompt when you lack documented context definitions—the output quality depends entirely on the quality and completeness of your input. If your team has not yet identified bounded contexts or mapped their relationships, start with a Domain-Driven Design discovery process before applying this assessment.

This prompt template is designed to be pasted directly into your AI system. It instructs the model to act as a domain architecture reviewer, analyzing the relationships between your defined bounded contexts. The output is a structured report that identifies coupling types, evaluates translation layers, and flags violations of your context map. Before running, you must replace the square-bracket placeholders with your specific architecture documentation, such as your context map, domain vision statement, and the list of contexts to analyze.

textCopy
You are a domain architecture reviewer specializing in Domain-Driven Design (DDD). Your task is to analyze the coupling between the bounded contexts described in the provided documentation. You will produce a structured assessment report that identifies relationship types, evaluates the adequacy of translation layers, and detects domain language leakage.

## Input Documentation
### Context Map
[CONTEXT_MAP_DOCUMENTATION]

### Domain Vision Statement
[DOMAIN_VISION_STATEMENT]

### Bounded Contexts to Analyze
[LIST_OF_BOUNDED_CONTEXTS]

### Specific Context Relationships to Review (Optional)
[SPECIFIC_RELATIONSHIPS_TO_REVIEW]

## Assessment Instructions
For each relationship between the specified bounded contexts, perform the following analysis:

1.  **Identify the Relationship Type:** Classify the relationship according to the DDD context map patterns (e.g., Partnership, Shared Kernel, Customer-Supplier, Conformist, Anticorruption Layer, Open Host Service, Published Language, Separate Ways).
2.  **Evaluate Translation Layer Adequacy:** For each relationship, assess the translation layer. Is it present? Is it sufficient to prevent domain concept leakage? Is it bidirectional where necessary?
3.  **Detect Domain Language Leakage:** Identify any instances where a concept, term, or event from one bounded context's ubiquitous language appears in another context without explicit translation. Provide specific examples from the documentation.
4.  **Flag Context Map Violations:** Check for any behavior that contradicts the declared relationship type in the context map (e.g., a Conformist context implementing its own independent logic, or a Partnership lacking a well-defined translation interface).

## Output Schema
Return your analysis as a JSON object with the following structure:
{
  "assessment_report": {
    "analyzed_contexts": ["string"],
    "coupling_relationships": [
      {
        "source_context": "string",
        "target_context": "string",
        "declared_relationship_type": "string",
        "actual_relationship_type": "string",
        "relationship_type_confidence": "high | medium | low",
        "translation_layer_assessment": {
          "is_present": true,
          "adequacy": "adequate | partially_adequate | inadequate | not_applicable",
          "notes": "string"
        },
        "domain_language_leakage": [
          {
            "leaked_term": "string",
            "source_context": "string",
            "target_context": "string",
            "evidence": "string"
          }
        ],
        "context_map_violations": [
          {
            "violation_type": "string",
            "description": "string",
            "evidence": "string"
          }
        ],
        "overall_coupling_health": "healthy | warning | critical"
      }
    ],
    "summary_of_findings": "A concise summary of the most critical coupling issues and risks."
  }
}

## Constraints
- Base your analysis strictly on the provided documentation. Do not infer or assume relationships not explicitly stated or clearly implied by the context map.
- If the documentation is insufficient to assess a specific point, set the confidence to "low" and note the missing information.
- For every violation or leakage flagged, you must provide direct evidence from the input documentation.

To adapt this template, replace the placeholders with your actual architecture artifacts. The [CONTEXT_MAP_DOCUMENTATION] should be a textual description or a structured representation of your context map. The [LIST_OF_BOUNDED_CONTEXTS] can be a simple list of names. If you want to focus the analysis, provide a subset of relationships in [SPECIFIC_RELATIONSHIPS_TO_REVIEW]; otherwise, the model will analyze all pairwise relationships. The output is a strict JSON schema, making it suitable for direct ingestion into an architecture dashboard or CI/CD pipeline. For high-stakes architecture decisions, always have a senior architect review the AI-generated assessment before accepting any refactoring recommendations.

This prompt is designed to be integrated into a structured architecture review pipeline, not run as a one-off chat interaction. The implementation harness should treat the prompt as a deterministic analysis step that receives a formalized domain model as input and produces a machine-readable coupling report as output. The primary integration points are: a pre-processing stage that assembles the bounded context inventory and relationship evidence, the LLM call itself, a post-processing validation layer that checks structural completeness and domain language consistency, and a human review gate for high-severity findings before they become action items. The harness must assume that the model will occasionally produce plausible-sounding but incorrect relationship classifications, so validation and human review are mandatory, not optional.

Begin by defining a strict input schema for the [CONTEXT_MAP] and [UBIQUITOUS_LANGUAGE_GLOSSARY] placeholders. The context map should be a structured JSON or YAML object listing each bounded context, its canonical name, its published domain events, its exposed API contracts, and its declared upstream/downstream relationships with relationship types (e.g., Partnership, Customer-Supplier, Conformist, Anticorruption Layer, Open Host Service, Published Language, Shared Kernel, Separate Ways). The glossary should map each context to a list of its core domain terms with definitions. Feed this structured input into the prompt template, replacing the placeholders programmatically. For the LLM call, use a model with strong reasoning capabilities and a low temperature setting (0.1–0.2) to maximize consistency across runs. Enable structured output mode if the model supports it, targeting the [OUTPUT_SCHEMA] defined in the prompt. If the model does not support native structured output, append a strict JSON-only instruction and implement a retry loop with a JSON parser as the first validation gate.

The post-processing validation layer must perform at least four checks before the output reaches a human reviewer. First, validate that every bounded context listed in the input context map appears in the output report's contexts array and that no hallucinated contexts were added. Second, for every reported relationship, verify that the from and to context names exist in the input and that the declared_type matches the input context map's declared relationship; flag any mismatch as a potential model error. Third, scan the domain_language_leakage array and cross-reference each flagged term against the input glossary to confirm the term actually belongs to the claimed source context; a term that appears in multiple glossaries by design is not a leak. Fourth, check that every translation_layer_assessment entry references a relationship that exists in the output and that the adequacy field is one of the allowed enum values. Any validation failure should trigger a retry with the original prompt plus the specific validation error message appended as a correction instruction. Limit retries to three attempts before escalating to human review with the failure log attached.

The human review gate should be triggered automatically for any report that contains severity: critical findings, translation_layer_assessment.adequacy: inadequate, or more than three domain_language_leakage entries. Present the reviewer with a diff view showing the input context map, the model's raw output, the validation results, and a summary of flagged items. The reviewer can approve the report as-is, correct specific findings, or reject the entire analysis and request a re-run with adjusted inputs. Store every approved report as a versioned artifact in the architecture decision log, including the prompt version, model version, input snapshot, and reviewer identity. For teams running this assessment periodically, implement a drift detection harness that compares the current report against the previous approved report and surfaces new coupling points, resolved leakages, or changed relationship types as a change log for the architecture review meeting.

Avoid wiring this prompt directly into an automated enforcement gate, such as a CI/CD pipeline blocker, without human review. The model can misclassify intentional shared kernels as violations, flag domain terms that are legitimately shared by design, or miss subtle coupling introduced through implicit conventions rather than explicit API calls. Use the prompt as a discovery and analysis tool that feeds human judgment, not as a policy enforcement engine. When integrating with existing architecture tooling, prefer to call this prompt from a scheduled workflow or an architecture review bot that posts findings to a dedicated channel, rather than blocking pull requests or deployments.