Prompt file imported from oliviasmim/workshop-dev-ai-workflow (.github/prompts/ddd-prompts/ddd-prompt-3-bounded-context.prompt.md). Copyright stays with the author.

DDD Prompt 3: Bounded Context Identification

Name: ddd-prompt-3-bounded-context
Author: oliviasmim

Objective

Define bounded contexts with explicit boundaries, identifying where different domain models apply.

Prompt

You are a Domain-Driven Design expert. Your task is to identify bounded contexts within this codebase based on the previously identified subdomains.

**Context:**
Use the subdomains identified in the previous analysis:
- Core Subdomains: [LIST_FROM_PROMPT_2]
- Supporting Subdomains: [LIST_FROM_PROMPT_2]
- Generic Subdomains: [LIST_FROM_PROMPT_2]

**Instructions:**
1. Analyze the codebase to identify bounded contexts by examining:
   - Domain model variations and inconsistencies
   - Data model differences for the same concepts
   - Language and terminology variations
   - Team boundaries and ownership
   - Integration patterns and data exchange
   - Database boundaries and data consistency requirements
   - Business process boundaries

2. For each bounded context, define:
   - **Clear boundaries**: What's inside vs outside
   - **Ubiquitous language**: Key terms and concepts
   - **Domain model**: Core entities and their relationships
   - **Integration needs**: How it communicates with other contexts

3. **Output Format:**

Bounded Context Analysis Report

Bounded Context Map

[High-level overview of all bounded contexts and their relationships]

Detailed Bounded Contexts

Bounded Context: [Context Name 1]

Purpose: [What business capability this context serves]
Subdomain Alignment: [Which subdomain(s) this context covers]
Boundaries:
- Included: [What's inside this context]
- Excluded: [What's explicitly outside]
Ubiquitous Language:
Core Domain Model:
- Entities: [Key business entities]
- Value Objects: [Important value objects]
- Aggregates: [Aggregate boundaries]
Codebase Mapping:
- Modules/Packages: [Specific code locations]
- Database Schemas: [Related data structures]
- APIs: [External interfaces]
Integration Points:
- Upstream Dependencies: [What this context depends on]
- Downstream Consumers: [What depends on this context]
- Integration Patterns: [How integration happens]

Context Relationships

[Context A] ↔ [Context B]

Relationship Type: [Customer-Supplier, Partnership, Shared Kernel, etc.]
Integration Mechanism: [Events, APIs, Shared Database, etc.]
Data Exchange: [What data is shared]

Boundary Analysis

Well-Defined Boundaries: [Contexts with clear boundaries]
Boundary Issues: [Areas where boundaries are unclear or problematic]
Recommendations: [Suggestions for improving boundary definition]

Strategic Design Recommendations

Context Consolidation Opportunities: [Contexts that might be merged]
Context Splitting Opportunities: [Contexts that might be split]
Integration Improvements: [Better ways to handle context integration]


**Guidelines:**
- A bounded context should have a consistent domain model
- Look for areas where the same concept has different meanings
- Consider data ownership and consistency boundaries
- Pay attention to integration patterns and coupling
- Focus on business capabilities rather than technical concerns
- Consider team structure and organizational boundaries

Please analyze this codebase and provide the bounded context identification report.

Expected Output

A comprehensive map of bounded contexts with clear boundaries and integration patterns.

# DDD Prompt 3: Bounded Context Identification ## Objective Define bounded contexts with explicit boundaries, identifying where different domain models apply. ## Prompt ``` You are a Domain-Driven Design expert. Your task is to identify bounded contexts within this codebase based on the previously identified subdomains. **Context:** Use the subdomains identified in the previous analysis: - Core Subdomains: [LIST_FROM_PROMPT_2] - Supporting Subdomains: [LIST_FROM_PROMPT_2] - Generic Subdomains: [LIST_FROM_PROMPT_2] **Instructions:** 1. Analyze the codebase to identify bounded contexts by examining: - Domain model variations and inconsistencies - Data model differences for the same concepts - Language and terminology variations - Team boundaries and ownership - Integration patterns and data exchange - Database boundaries and data consistency requirements - Business process boundaries 2. For each bounded context, define: - **Clear boundaries**: What's inside vs outside - **Ubiquitous language**: Key terms and concepts - **Domain model**: Core entities and their relationships - **Integration needs**: How it communicates with other contexts 3. **Output Format:** ``` ## Bounded Context Analysis Report ### Bounded Context Map [High-level overview of all bounded contexts and their relationships] ### Detailed Bounded Contexts #### Bounded Context: [Context Name 1] - **Purpose:** [What business capability this context serves] - **Subdomain Alignment:** [Which subdomain(s) this context covers] - **Boundaries:** - **Included:** [What's inside this context] - **Excluded:** [What's explicitly outside] - **Ubiquitous Language:** - [Term 1]: [Definition] - [Term 2]: [Definition] - [Term 3]: [Definition] - **Core Domain Model:** - **Entities:** [Key business entities] - **Value Objects:** [Important value objects] - **Aggregates:** [Aggregate boundaries] - **Codebase Mapping:** - **Modules/Packages:** [Specific code locations] - **Database Schemas:** [Related data structures] - **APIs:** [External interfaces] - **Integration Points:** - **Upstream Dependencies:** [What this context depends on] - **Downstream Consumers:** [What depends on this context] - **Integration Patterns:** [How integration happens] ### Context Relationships #### [Context A] ↔ [Context B] - **Relationship Type:** [Customer-Supplier, Partnership, Shared Kernel, etc.] - **Integration Mechanism:** [Events, APIs, Shared Database, etc.] - **Data Exchange:** [What data is shared] ### Boundary Analysis - **Well-Defined Boundaries:** [Contexts with clear boundaries] - **Boundary Issues:** [Areas where boundaries are unclear or problematic] - **Recommendations:** [Suggestions for improving boundary definition] ### Strategic Design Recommendations - **Context Consolidation Opportunities:** [Contexts that might be merged] - **Context Splitting Opportunities:** [Contexts that might be split] - **Integration Improvements:** [Better ways to handle context integration] ``` **Guidelines:** - A bounded context should have a consistent domain model - Look for areas where the same concept has different meanings - Consider data ownership and consistency boundaries - Pay attention to integration patterns and coupling - Focus on business capabilities rather than technical concerns - Consider team structure and organizational boundaries Please analyze this codebase and provide the bounded context identification report. ``` ## Expected Output A comprehensive map of bounded contexts with clear boundaries and integration patterns.

{ "prompt": "# DDD Prompt 3: Bounded Context Identification\n\n## Objective\nDefine bounded contexts with explicit boundaries, identifying where different domain models apply.\n\n## Prompt\n\n```\nYou are a Domain-Driven Design expert. Your task is to identify bounded contexts within this codebase based on the previously identified subdomains.\n\n**Context:**\nUse the subdomains identified in the previous analysis:\n- Core Subdomains: [LIST_FROM_PROMPT_2]\n- Supporting Subdomains: [LIST_FROM_PROMPT_2]\n- Generic Subdomains: [LIST_FROM_PROMPT_2]\n\n**Instructions:**\n1. Analyze the codebase to identify bounded contexts by examining:\n - Domain model variations and inconsistencies\n - Data model differences for the same concepts\n - Language and terminology variations\n - Team boundaries and ownership\n - Integration patterns and data exchange\n - Database boundaries and data consistency requirements\n - Business process boundaries\n\n2. For each bounded context, define:\n - **Clear boundaries**: What's inside vs outside\n - **Ubiquitous language**: Key terms and concepts\n - **Domain model**: Core entities and their relationships\n - **Integration needs**: How it communicates with other contexts\n\n3. **Output Format:**\n ```\n ## Bounded Context Analysis Report\n \n ### Bounded Context Map\n [High-level overview of all bounded contexts and their relationships]\n \n ### Detailed Bounded Contexts\n \n #### Bounded Context: [Context Name 1]\n - **Purpose:** [What business capability this context serves]\n - **Subdomain Alignment:** [Which subdomain(s) this context covers]\n - **Boundaries:**\n - **Included:** [What's inside this context]\n - **Excluded:** [What's explicitly outside]\n - **Ubiquitous Language:**\n - [Term 1]: [Definition]\n - [Term 2]: [Definition]\n - [Term 3]: [Definition]\n - **Core Domain Model:**\n - **Entities:** [Key business entities]\n - **Value Objects:** [Important value objects]\n - **Aggregates:** [Aggregate boundaries]\n - **Codebase Mapping:**\n - **Modules/Packages:** [Specific code locations]\n - **Database Schemas:** [Related data structures]\n - **APIs:** [External interfaces]\n - **Integration Points:**\n - **Upstream Dependencies:** [What this context depends on]\n - **Downstream Consumers:** [What depends on this context]\n - **Integration Patterns:** [How integration happens]\n \n ### Context Relationships\n #### [Context A] ↔ [Context B]\n - **Relationship Type:** [Customer-Supplier, Partnership, Shared Kernel, etc.]\n - **Integration Mechanism:** [Events, APIs, Shared Database, etc.]\n - **Data Exchange:** [What data is shared]\n \n ### Boundary Analysis\n - **Well-Defined Boundaries:** [Contexts with clear boundaries]\n - **Boundary Issues:** [Areas where boundaries are unclear or problematic]\n - **Recommendations:** [Suggestions for improving boundary definition]\n \n ### Strategic Design Recommendations\n - **Context Consolidation Opportunities:** [Contexts that might be merged]\n - **Context Splitting Opportunities:** [Contexts that might be split]\n - **Integration Improvements:** [Better ways to handle context integration]\n ```\n\n**Guidelines:**\n- A bounded context should have a consistent domain model\n- Look for areas where the same concept has different meanings\n- Consider data ownership and consistency boundaries\n- Pay attention to integration patterns and coupling\n- Focus on business capabilities rather than technical concerns\n- Consider team structure and organizational boundaries\n\nPlease analyze this codebase and provide the bounded context identification report.\n```\n\n## Expected Output\nA comprehensive map of bounded contexts with clear boundaries and integration patterns.", "variables": [], "notes": "2. For each bounded context, define: - **Clear boundaries**: What's inside vs outside - **Ubiquitous language**: Key terms and concepts - **Domain model**: Core entities and their relationships - **Integration needs**: How it communicates with other contexts", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/oliviasmim/workshop-dev-ai-workflow", "path": ".github/prompts/ddd-prompts/ddd-prompt-3-bounded-context.prompt.md", "ref": "b5a380fddc8d74f1db14539ae14a3b5a30267671", "url": "https://github.com/oliviasmim/workshop-dev-ai-workflow/blob/b5a380fddc8d74f1db14539ae14a3b5a30267671/.github/prompts/ddd-prompts/ddd-prompt-3-bounded-context.prompt.md", "key": "oliviasmim/workshop-dev-ai-workflow/.github/prompts/ddd-prompts/ddd-prompt-3-bounded-context.prompt.md" } } }

ddd-prompt-3-bounded-context

About