Anti-Corruption Layer Design Justification Prompt

This prompt is for integration architects and senior backend engineers who must decide whether to place an Anti-Corruption Layer (ACL) between two bounded contexts. The job-to-be-done is producing a structured, defensible justification document that weighs the cost of building and maintaining an ACL against the risk of allowing one context's model to leak into another. Use this prompt when you have two known bounded contexts with documented or inferred models, a specific integration point under design, and a need for a written rationale that can survive architecture review. The ideal user already understands Domain-Driven Design patterns and is not looking for an introduction to ACLs, conformist patterns, or separate ways—they need a rigorous trade-off analysis.

Do not use this prompt when the two contexts are not yet defined, when the integration is purely technical with no domain translation (e.g., a simple data passthrough), or when you are early in domain discovery and still identifying bounded contexts. In those cases, start with the Bounded Context Discovery Prompt or the Service Boundary Candidate Identification Prompt. Also avoid this prompt if you need a real-time runtime decision—this is a design-time analysis tool, not a production router. The output is a document for human review, not a machine-readable configuration. For high-risk domains such as finance, healthcare, or safety-critical systems, the justification must include explicit human review gates and evidence grounding requirements before any implementation proceeds.

Before running this prompt, gather the upstream context model (entities, aggregates, value objects, and business rules), the downstream context model, the specific integration use cases, and any existing translation logic or shared kernel agreements. The prompt expects these as structured inputs in the [UPSTREAM_CONTEXT_MODEL], [DOWNSTREAM_CONTEXT_MODEL], and [INTEGRATION_USE_CASES] placeholders. If you lack formal context models, you can substitute API contracts, database schemas, or event schemas, but the analysis quality will degrade. The output is a justification document with translation complexity assessment, maintenance cost estimate, alternatives analysis, and a clear recommendation. Wire this into your architecture review process as a required artifact before any ACL implementation begins, and version the justification alongside the integration code so future teams understand why the decision was made.

The following prompt template is designed to be copied directly into your AI harness. It uses square-bracket placeholders for all dynamic inputs, allowing you to adapt it for any integration scenario. The prompt forces the model to structure its output as a formal justification document, weighing the complexity of translation against the long-term maintenance cost and comparing the ACL pattern against viable alternatives like Conformist and Separate Ways.

textCopy
You are a senior integration architect evaluating the need for an Anti-Corruption Layer (ACL).

Given the following two bounded contexts, produce a structured ACL Justification Document.

**Context A (Upstream/External):**
[UPSTREAM_CONTEXT_DESCRIPTION]

**Context B (Downstream/Internal):**
[DOWNSTREAM_CONTEXT_DESCRIPTION]

**Integration Point:**
[INTEGRATION_POINT_DESCRIPTION]

**Constraints:**
[CONSTRAINTS]

**Output Structure:**
1.  **Translation Complexity Assessment:** Score the semantic and syntactic mismatch between the two models (Low/Medium/High). List at least three specific concepts that require translation.
2.  **Maintenance Cost Estimate:** Estimate the relative effort to build and maintain the ACL (Low/Medium/High). Justify with factors like upstream volatility and team cognitive load.
3.  **Alternatives Analysis:** Evaluate the Conformist pattern (Context B adopts Context A's model directly) and the Separate Ways pattern (no integration). For each, state the primary benefit and the primary risk in this specific scenario.
4.  **Recommendation:** Recommend whether to implement an ACL, and if so, define its core responsibility in one sentence. If not, specify which alternative pattern is preferred and why.

**Response Rules:**
- Do not propose a full implementation plan.
- If the translation complexity is Low and the upstream context is stable, default to questioning the need for an ACL.
- Use precise domain language from the provided descriptions.

To adapt this template, replace the placeholders with concrete details from your design session. [UPSTREAM_CONTEXT_DESCRIPTION] should include the model's key entities and behaviors, while [CONSTRAINTS] can specify team topology, regulatory requirements, or performance budgets. For high-risk domains like finance or healthcare, you should add a [RISK_LEVEL] field and a rule requiring the model to flag any recommendation that could lead to data integrity issues. Always validate the output against your own architectural principles before logging it as an official decision record.

This prompt is designed to be called programmatically as part of an architecture review pipeline, not as a one-off chat interaction. The typical integration point is a design review bot, an internal architecture portal, or a CI/CD pipeline gate that triggers when a team proposes a new integration between two bounded contexts. The caller must supply the two context descriptions, the integration scenario, and any known constraints. The model returns a structured JSON justification that downstream systems can parse, store, and compare against previous decisions.

Wire the prompt into an application by building a thin service wrapper that accepts a POST request with the required input fields, hydrates the template, calls the model API, and validates the response against the expected output schema before persisting the result. Use a JSON schema validator to confirm that all required fields are present, that the recommendation field is one of the allowed enum values (ACL_WARRANTED, ACL_OPTIONAL, ACL_UNNECESSARY), and that the translation_complexity and maintenance_cost fields are integers between 1 and 5. If validation fails, retry once with the validation errors appended as additional context. If the retry also fails, log the failure and route the request to a human review queue rather than silently accepting a malformed output. For model choice, prefer a model with strong structured output capabilities and a context window large enough to hold both context descriptions plus the prompt. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable. Set temperature to 0.2 or lower to reduce variance in the structured fields. Enable structured output mode if the model API supports it, passing the full JSON schema as a constraint rather than relying on prompt instructions alone.

Store every generated justification alongside the input parameters, model version, timestamp, and the validator pass/fail status. This audit trail is essential because architecture decisions are revisited months later when the integration evolves. If the prompt is used in a regulated environment, require a human architect to approve the output before it becomes a recorded decision. The approval step should display the structured justification in a review UI that highlights the recommendation, the risk factors, and the alternatives analysis. Do not auto-apply the recommendation to downstream systems such as Jira or architecture registries without human sign-off. For teams using RAG, you can optionally ground the prompt by retrieving prior ACL decisions from the same system landscape and including them as [EXAMPLES] to improve consistency across related integrations.