Bounded Context Integration Pattern Selection Prompt

This prompt is for a domain architect or technical lead who must choose an integration pattern between two or more bounded contexts and needs a structured trade-off analysis, not just a pattern name. The job-to-be-done is: given a description of the contexts, their relationship, and the non-functional requirements, produce a recommended integration pattern (e.g., Anti-Corruption Layer, Open Host Service, Published Language, Customer/Supplier, Conformist, Separate Ways, Partnership) with explicit rationale, implementation complexity estimate, and a list of risks the team must mitigate before committing. The ideal user has already completed a context map and understands the domain relationship type, but needs help translating that relationship into a concrete integration design.

Use this prompt when the team is debating between patterns, when an existing integration is causing friction and needs re-evaluation, or when a new context is being introduced and the integration contract must be defined before implementation starts. The prompt requires [CONTEXT_A_DESCRIPTION], [CONTEXT_B_DESCRIPTION], [RELATIONSHIP_TYPE], [NON_FUNCTIONAL_REQUIREMENTS], and [CURRENT_PAIN_POINTS] as inputs. It works best when the team has already classified the subdomains (Core, Supporting, Generic) and understands the organizational relationship between the teams owning each context. The prompt is designed to surface hidden coupling risks, translation overhead, and team coordination costs that are often invisible in a simple pattern diagram.

Do not use this prompt when the bounded contexts themselves are poorly defined or when the team lacks a context map. If the boundaries are still in discovery, use the Bounded Context Boundary Review Prompt first. Do not use this prompt for selecting communication protocols (REST, gRPC, messaging) in isolation—it focuses on the integration pattern, not the transport. The output is a design recommendation, not a buildable specification; downstream work will require the Anti-Corruption Layer Design Evaluation Prompt or the Domain Event Schema Design Review Prompt to turn the recommendation into implementation artifacts. If the integration involves regulated data or financial transactions, the output must be reviewed by a human architect before any implementation commitment, and the prompt's [RISK_LEVEL] placeholder should be set to 'high' to trigger additional scrutiny in the response.

This prompt template is designed to be copied directly into your AI harness, IDE, or orchestration layer. It accepts two bounded context descriptions and a set of integration requirements, then produces a structured recommendation with trade-off analysis. The square-bracket placeholders represent variables your application must supply before sending the request to the model. Do not ship this prompt with unresolved placeholders in production.

textCopy
You are a domain-driven design architect reviewing integration patterns between two bounded contexts.

## Context A
[CONTEXT_A_DESCRIPTION]

## Context B
[CONTEXT_B_DESCRIPTION]

## Integration Requirements
- Data direction: [DATA_DIRECTION]
- Consistency needs: [CONSISTENCY_REQUIREMENTS]
- Latency tolerance: [LATENCY_TOLERANCE]
- Team ownership: [TEAM_OWNERSHIP_MODEL]
- Existing contracts: [EXISTING_CONTRACTS]
- Scale and throughput: [SCALE_THROUGHPUT]

## Constraints
[CONSTRAINTS]

## Output Schema
Return a JSON object with this exact structure:
{
  "recommended_pattern": "Anti-Corruption Layer | Open Host Service | Published Language | Conformist | Customer-Supplier | Separate Ways | Partnership | Shared Kernel",
  "confidence": "high | medium | low",
  "rationale": "2-3 sentence explanation of why this pattern fits the requirements",
  "trade_offs": [
    {
      "dimension": "consistency | latency | autonomy | complexity | maintainability | team_velocity",
      "risk": "high | medium | low",
      "description": "specific risk for this integration"
    }
  ],
  "implementation_complexity": "high | medium | low",
  "implementation_steps": ["ordered list of 3-5 concrete implementation steps"],
  "alternative_patterns": [
    {
      "pattern": "alternative pattern name",
      "when_to_consider": "condition that would make this pattern preferable"
    }
  ],
  "warning_flags": ["list of conditions that would invalidate this recommendation"]
}

## Evaluation Criteria
- Prefer patterns that preserve context autonomy when teams are separate.
- If both contexts are owned by the same team, Shared Kernel becomes more viable.
- If Context B cannot adapt to Context A's model, Anti-Corruption Layer is mandatory.
- If the upstream context publishes a well-defined API, Open Host Service should be considered.
- Flag Separate Ways if integration cost exceeds the value of coordination.

To adapt this template, replace each placeholder with data from your architecture review process. [CONTEXT_A_DESCRIPTION] and [CONTEXT_B_DESCRIPTION] should include the domain responsibility, team ownership, and key aggregates for each context. [DATA_DIRECTION] must specify whether data flows unidirectionally or bidirectionally. [CONSISTENCY_REQUIREMENTS] should capture whether eventual consistency is acceptable or strong consistency is required. If any input is unknown, set the value to "UNKNOWN" so the model can flag it as a risk rather than hallucinating an assumption. Before deploying, run this prompt against at least three known context pairs where you already know the correct pattern, and verify the model's recommendations match your architectural judgment.

This prompt is designed to be called from an architecture review pipeline, a design decision CLI, or a pull request workflow where a team proposes a new integration between bounded contexts. The application layer is responsible for assembling the [CONTEXT_MAP], [NEW_INTEGRATION_DESCRIPTION], and [CONSTRAINTS] from existing architecture documentation, ADRs, or structured forms before invoking the model. Because integration pattern selection has long-term architectural consequences, the harness must treat the model output as a recommendation, not a final decision. The output should be persisted alongside the architecture decision record it supports, with clear attribution that the analysis was AI-assisted.

Implement a two-phase validation gate. First, validate the output schema: confirm the JSON contains the required fields (recommended_pattern, trade_off_analysis, implementation_complexity, risks, alternatives_considered) and that recommended_pattern matches one of the allowed enum values (ACL, Open Host, Published Language, Customer-Supplier, Conformist, Separate Ways, Partnership). Reject and retry once if the schema fails. Second, route the output for human review when the implementation_complexity score exceeds a threshold (e.g., 7/10) or when the risks array contains items flagged as severity: high. Log every invocation with the input context hash, model version, output pattern, and reviewer decision for auditability. For teams using an architecture knowledge base, retrieve the existing context map via RAG before calling the prompt so the model works from current, grounded information rather than stale or assumed boundaries.

Avoid wiring this prompt directly into a CI/CD gate that blocks merges. Integration pattern selection involves trade-off judgment that benefits from discussion. Instead, post the recommendation as a comment on the design document or ADR pull request, tagged for the architecture review group. If the model returns low confidence or flags contradictory constraints in the input, escalate to a synchronous review channel rather than silently accepting the best-guess output. The harness should also track pattern recommendations over time: if the same two contexts receive different pattern recommendations within a short window, surface that inconsistency for human investigation before the team commits to an implementation path.