Bounded Context Discovery Prompt

This prompt is for domain architects and engineering leads who need to transform raw business capability descriptions, event storming outputs, or existing system documentation into a structured bounded context map. The job-to-be-done is not just drawing boxes on a whiteboard—it's producing a rigorous, repeatable analysis that identifies candidate contexts, their responsibility boundaries, ubiquitous language terms, and integration points. Use this when you are starting a decomposition effort, validating an existing service map against domain logic, or preparing for a Strangler Fig migration where getting the boundaries wrong upfront creates a distributed monolith that is more expensive to fix than the original system.

The ideal user has access to domain expert interviews, business process documentation, event storming artifacts, or a working knowledge of the system's core capabilities. The prompt requires a [DOMAIN_DESCRIPTION] input that can be a narrative, a list of business capabilities, or a set of domain events. You should also provide [UBIQUITOUS_LANGUAGE_TERMS] as a glossary of known domain terms to ground the analysis. The prompt works best when the domain is complex enough to have multiple candidate boundaries but not so poorly understood that no stakeholder can articulate what the system does. It is not a replacement for collaborative domain modeling with domain experts—it is a structured synthesis tool that accelerates the analysis phase and surfaces boundary conflicts before they become code.

Do not use this prompt when the domain is trivial (a single context with no meaningful decomposition), when you lack any domain documentation or expert access (the model will hallucinate plausible but wrong boundaries), or when the output will be treated as a final architecture decision without human review. The prompt produces candidate contexts that require validation against team structures, deployment constraints, and real-world coupling data. It is a discovery accelerator, not an architecture oracle. For regulated domains like healthcare or finance, always run the output through a domain expert review gate and cross-reference against compliance requirements before committing to service boundaries.

This prompt template is designed to be copied directly into your AI harness. It uses square-bracket placeholders for all dynamic inputs, ensuring you can adapt it to different domains, systems, and organizational contexts without modifying the core instruction structure. The template expects you to provide business capability descriptions, existing system context, and output format requirements before execution.

textCopy
You are a domain-driven design architect analyzing business capabilities to identify candidate bounded contexts. Your task is to produce a context map that defines domain terminology, responsibility boundaries, and integration points between contexts.

## INPUT
[BUSINESS_CAPABILITY_DESCRIPTIONS]

## EXISTING SYSTEM CONTEXT
[EXISTING_SYSTEM_CONTEXT]

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT SCHEMA
You must produce a JSON object with the following structure:
{
  "bounded_contexts": [
    {
      "name": "string",
      "description": "string",
      "core_responsibilities": ["string"],
      "ubiquitous_language_terms": [
        {
          "term": "string",
          "definition": "string",
          "context_specific_meaning": "string"
        }
      ],
      "owning_team": "string or null",
      "key_aggregates": ["string"],
      "domain_events_published": ["string"],
      "domain_events_consumed": ["string"]
    }
  ],
  "context_relationships": [
    {
      "upstream_context": "string",
      "downstream_context": "string",
      "relationship_type": "partnership | customer-supplier | conformist | anti-corruption-layer | open-host-service | published-language | separate-ways | shared-kernel",
      "integration_mechanism": "string",
      "translation_layer_required": true or false,
      "justification": "string"
    }
  ],
  "overlap_detection": [
    {
      "context_a": "string",
      "context_b": "string",
      "overlapping_concept": "string",
      "resolution_recommendation": "string",
      "severity": "high | medium | low"
    }
  ],
  "boundary_confidence_scores": [
    {
      "context_name": "string",
      "cohesion_score": 0.0 to 1.0,
      "coupling_score": 0.0 to 1.0,
      "business_alignment_score": 0.0 to 1.0,
      "overall_confidence": 0.0 to 1.0,
      "risk_factors": ["string"]
    }
  ]
}

## INSTRUCTIONS
1. Analyze each business capability to identify distinct domains with separate ubiquitous languages.
2. For each candidate bounded context, define its core responsibilities and key domain terminology.
3. Identify integration points between contexts and classify each relationship using the standard DDD relationship types.
4. Detect overlapping concepts where two contexts appear to own the same responsibility or use conflicting terminology for the same concept.
5. Assign confidence scores based on cohesion within contexts, coupling between contexts, and alignment with business capabilities.
6. Flag any contexts that appear too large (low cohesion) or too small (trivial responsibility) with specific risk factors.
7. If [CONSTRAINTS] specify organizational or technical boundaries, incorporate those into your analysis.

## VALIDATION RULES
- Every bounded context must have at least one core responsibility.
- Every ubiquitous language term must have a context-specific meaning distinct from generic definitions.
- Context relationships must reference only contexts defined in the bounded_contexts array.
- Overlap detection entries must reference two distinct contexts.
- Confidence scores must be between 0.0 and 1.0 inclusive.
- If no overlaps are detected, return an empty overlap_detection array.

After copying this template, replace each square-bracket placeholder with your actual inputs. The [BUSINESS_CAPABILITY_DESCRIPTIONS] should contain structured descriptions of what your business does—process flows, user journeys, or capability maps. The [EXISTING_SYSTEM_CONTEXT] should describe current system boundaries, database ownership, and team structures. The [CONSTRAINTS] placeholder accepts organizational policies, regulatory requirements, or technical limitations that affect boundary decisions. If you don't have constraints, replace it with 'No specific constraints.'

Before wiring this into production, validate the output against the schema using a JSON schema validator. Run at least three test cases: a well-structured domain with clear boundaries, an ambiguous domain with overlapping responsibilities, and a domain with regulatory constraints. Compare the overlap detection results against manual domain analysis to calibrate the model's sensitivity. For high-stakes architectural decisions, always have a domain expert review the context map before committing to service boundaries.

The Bounded Context Discovery prompt is designed to be used as a structured analysis step within a broader architecture review workflow, not as a standalone chat interaction. It accepts a domain description, business capability inventory, and existing system context as inputs, and produces a candidate context map with terminology, boundaries, and integration points. Because the output directly influences service decomposition decisions that carry multi-year cost and complexity implications, the implementation harness must include validation checks, human review gates, and traceable rationale before any output is accepted as an architectural decision.

Wire the prompt into an application by constructing a request pipeline that assembles the three required inputs—[DOMAIN_DESCRIPTION], [BUSINESS_CAPABILITIES], and [EXISTING_SYSTEM_CONTEXT]—from structured sources such as architecture documentation, event storming outputs, or capability models. Before calling the model, validate that each input field is non-empty and contains sufficient detail (at minimum, a paragraph of domain narrative and a list of at least five distinct business capabilities). After receiving the model response, parse the output against the expected schema: a JSON object containing bounded_contexts (array of context objects with name, core_responsibilities, key_entities, ubiquitous_language_terms, and integration_points), context_map (a matrix or edge list describing relationships between contexts), and overlap_concerns (array of potential boundary conflicts). Run automated validation checks including: (1) every bounded context must have at least one distinct responsibility not fully claimed by another context, (2) integration points must reference valid context names, and (3) overlap concerns must cite specific contexts. If validation fails, retry with the error details appended to the prompt as [PREVIOUS_OUTPUT_ERRORS].

For high-stakes architecture decisions, route validated outputs to a human review queue rather than auto-applying them. The review interface should display the original inputs, the generated context map, any overlap concerns flagged by the model, and the validation results. Reviewers should confirm that contexts align with organizational team boundaries (Conway's Law check), that no critical business capability is orphaned, and that integration points reflect actual system dependencies. Log every prompt invocation with input hashes, output snapshots, validation results, reviewer identity, and final disposition (accepted, revised, rejected) to create an audit trail suitable for architecture decision records. Avoid using this prompt on domains where the business capability inventory is incomplete or where the existing system context is poorly understood—garbage-in, garbage-out applies with high consequence here.