Prompt file imported from oliviasmim/ai-refactoring-resources (.github/prompts/copilot-prompts/ddd-prompt-4-microservices-design.prompt.md). Copyright stays with the author.

DDD Prompt 4: Microservices Design

Name: ddd-prompt-4-microservices-design
Author: oliviasmim

Objective

Design microservices architecture based on the identified bounded contexts, following DDD principles and microservices best practices.

Prompt

You are a solution architect and microservices expert. Your task is to design a microservices architecture based on the bounded contexts identified in the previous analysis.

**Context:**
Use the bounded contexts identified in the previous analysis: [LIST_FROM_PROMPT_3]

**Microservices Design Principles:**
- **Single Responsibility Principle (SRP)**: A microservice should do one thing well and have a single reason to change
- **Bounded Context Alignment**: Each microservice should align with one bounded context
- **Data Ownership**: Each microservice should own its data and not share databases
- **Autonomous Teams**: Microservices should enable independent team development and deployment
- **Business Capability Focus**: Services should be organized around business capabilities

**Instructions:**
1. Analyze each bounded context and determine microservice design by considering:
   - Business capability alignment
   - Data consistency requirements
   - Team ownership and development independence
   - Scalability and performance requirements
   - Integration complexity
   - Deployment and operational considerations

2. **Output Format:**

Microservices Architecture Design

Architecture Overview

[High-level description of the proposed microservices architecture]

Microservices Catalog

Microservice: [Service Name 1]

Bounded Context: [Associated bounded context]
Business Capability: [Primary business capability served]
Responsibilities:
- [Responsibility 1]
- [Responsibility 2]
- [...]
Data Ownership:
- Primary Entities: [Entities this service owns]
- Database Schema: [Suggested data storage approach]
APIs:
- REST Endpoints: [Key API operations]
- Events Published: [Domain events this service publishes]
- Events Consumed: [Domain events this service consumes]
Dependencies:
- Upstream Services: [Services this depends on]
- External Systems: [External integrations]
Codebase Mapping:
- Current Modules: [Existing code that would belong to this service]
- Migration Complexity: [High/Medium/Low complexity to extract]
Team Ownership: [Suggested team or organizational unit]

Service Interaction Patterns

Synchronous Communication

Service A → Service B: [API calls, purpose, data exchanged]

Asynchronous Communication

Event: [Event Name]
- Publisher: [Service that publishes]
- Subscribers: [Services that consume]
- Purpose: [Why this event exists]

Data Management Strategy

Database per Service: [How to achieve data independence]
Data Consistency: [Eventual consistency patterns]
Shared Reference Data: [How to handle shared data]

Cross-Cutting Concerns

Authentication/Authorization: [Approach for security]
Logging and Monitoring: [Observability strategy]
Configuration Management: [How services get configuration]
API Gateway: [Entry point and routing strategy]

Migration Strategy

Phase 1: [Initial extraction]

Services to Extract: [List of services]
Migration Approach: [Strangler fig, big bang, etc.]
Risk Assessment: [Key risks and mitigation]

Phase 2: [Next phase]

[Continue with additional phases]

Architecture Quality Assessment

Service Cohesion: [How well-focused each service is]
Service Coupling: [Dependencies between services]
Data Consistency: [How data consistency is maintained]
Scalability: [Independent scaling capabilities]
Fault Tolerance: [Resilience patterns]

Recommendations

Quick Wins: [Easy services to extract first]
Complex Extractions: [Services requiring careful planning]
Technology Considerations: [Tech stack recommendations]
Operational Readiness: [Infrastructure and tooling needs]


**Guidelines:**
- Prefer smaller, focused services over large services
- Ensure each service can be developed and deployed independently
- Minimize data sharing between services
- Design for failure and resilience
- Consider the organizational structure (Conway's Law)
- Balance service granularity with operational complexity

Please analyze the bounded contexts and provide the microservices architecture design.

Expected Output

A comprehensive microservices architecture design with clear service boundaries, responsibilities, and migration strategy.

# DDD Prompt 4: Microservices Design ## Objective Design microservices architecture based on the identified bounded contexts, following DDD principles and microservices best practices. ## Prompt ``` You are a solution architect and microservices expert. Your task is to design a microservices architecture based on the bounded contexts identified in the previous analysis. **Context:** Use the bounded contexts identified in the previous analysis: [LIST_FROM_PROMPT_3] **Microservices Design Principles:** - **Single Responsibility Principle (SRP)**: A microservice should do one thing well and have a single reason to change - **Bounded Context Alignment**: Each microservice should align with one bounded context - **Data Ownership**: Each microservice should own its data and not share databases - **Autonomous Teams**: Microservices should enable independent team development and deployment - **Business Capability Focus**: Services should be organized around business capabilities **Instructions:** 1. Analyze each bounded context and determine microservice design by considering: - Business capability alignment - Data consistency requirements - Team ownership and development independence - Scalability and performance requirements - Integration complexity - Deployment and operational considerations 2. **Output Format:** ``` ## Microservices Architecture Design ### Architecture Overview [High-level description of the proposed microservices architecture] ### Microservices Catalog #### Microservice: [Service Name 1] - **Bounded Context:** [Associated bounded context] - **Business Capability:** [Primary business capability served] - **Responsibilities:** - [Responsibility 1] - [Responsibility 2] - [...] - **Data Ownership:** - **Primary Entities:** [Entities this service owns] - **Database Schema:** [Suggested data storage approach] - **APIs:** - **REST Endpoints:** [Key API operations] - **Events Published:** [Domain events this service publishes] - **Events Consumed:** [Domain events this service consumes] - **Dependencies:** - **Upstream Services:** [Services this depends on] - **External Systems:** [External integrations] - **Codebase Mapping:** - **Current Modules:** [Existing code that would belong to this service] - **Migration Complexity:** [High/Medium/Low complexity to extract] - **Team Ownership:** [Suggested team or organizational unit] ### Service Interaction Patterns #### Synchronous Communication - **Service A → Service B:** [API calls, purpose, data exchanged] #### Asynchronous Communication - **Event:** [Event Name] - **Publisher:** [Service that publishes] - **Subscribers:** [Services that consume] - **Purpose:** [Why this event exists] ### Data Management Strategy - **Database per Service:** [How to achieve data independence] - **Data Consistency:** [Eventual consistency patterns] - **Shared Reference Data:** [How to handle shared data] ### Cross-Cutting Concerns - **Authentication/Authorization:** [Approach for security] - **Logging and Monitoring:** [Observability strategy] - **Configuration Management:** [How services get configuration] - **API Gateway:** [Entry point and routing strategy] ### Migration Strategy #### Phase 1: [Initial extraction] - **Services to Extract:** [List of services] - **Migration Approach:** [Strangler fig, big bang, etc.] - **Risk Assessment:** [Key risks and mitigation] #### Phase 2: [Next phase] [Continue with additional phases] ### Architecture Quality Assessment - **Service Cohesion:** [How well-focused each service is] - **Service Coupling:** [Dependencies between services] - **Data Consistency:** [How data consistency is maintained] - **Scalability:** [Independent scaling capabilities] - **Fault Tolerance:** [Resilience patterns] ### Recommendations - **Quick Wins:** [Easy services to extract first] - **Complex Extractions:** [Services requiring careful planning] - **Technology Considerations:** [Tech stack recommendations] - **Operational Readiness:** [Infrastructure and tooling needs] ``` **Guidelines:** - Prefer smaller, focused services over large services - Ensure each service can be developed and deployed independently - Minimize data sharing between services - Design for failure and resilience - Consider the organizational structure (Conway's Law) - Balance service granularity with operational complexity Please analyze the bounded contexts and provide the microservices architecture design. ``` ## Expected Output A comprehensive microservices architecture design with clear service boundaries, responsibilities, and migration strategy.

{ "prompt": "# DDD Prompt 4: Microservices Design\n\n## Objective\nDesign microservices architecture based on the identified bounded contexts, following DDD principles and microservices best practices.\n\n## Prompt\n\n```\nYou are a solution architect and microservices expert. Your task is to design a microservices architecture based on the bounded contexts identified in the previous analysis.\n\n**Context:**\nUse the bounded contexts identified in the previous analysis: [LIST_FROM_PROMPT_3]\n\n**Microservices Design Principles:**\n- **Single Responsibility Principle (SRP)**: A microservice should do one thing well and have a single reason to change\n- **Bounded Context Alignment**: Each microservice should align with one bounded context\n- **Data Ownership**: Each microservice should own its data and not share databases\n- **Autonomous Teams**: Microservices should enable independent team development and deployment\n- **Business Capability Focus**: Services should be organized around business capabilities\n\n**Instructions:**\n1. Analyze each bounded context and determine microservice design by considering:\n - Business capability alignment\n - Data consistency requirements\n - Team ownership and development independence\n - Scalability and performance requirements\n - Integration complexity\n - Deployment and operational considerations\n\n2. **Output Format:**\n ```\n ## Microservices Architecture Design\n \n ### Architecture Overview\n [High-level description of the proposed microservices architecture]\n \n ### Microservices Catalog\n \n #### Microservice: [Service Name 1]\n - **Bounded Context:** [Associated bounded context]\n - **Business Capability:** [Primary business capability served]\n - **Responsibilities:**\n - [Responsibility 1]\n - [Responsibility 2]\n - [...]\n - **Data Ownership:**\n - **Primary Entities:** [Entities this service owns]\n - **Database Schema:** [Suggested data storage approach]\n - **APIs:**\n - **REST Endpoints:** [Key API operations]\n - **Events Published:** [Domain events this service publishes]\n - **Events Consumed:** [Domain events this service consumes]\n - **Dependencies:**\n - **Upstream Services:** [Services this depends on]\n - **External Systems:** [External integrations]\n - **Codebase Mapping:**\n - **Current Modules:** [Existing code that would belong to this service]\n - **Migration Complexity:** [High/Medium/Low complexity to extract]\n - **Team Ownership:** [Suggested team or organizational unit]\n \n ### Service Interaction Patterns\n #### Synchronous Communication\n - **Service A → Service B:** [API calls, purpose, data exchanged]\n \n #### Asynchronous Communication\n - **Event:** [Event Name]\n - **Publisher:** [Service that publishes]\n - **Subscribers:** [Services that consume]\n - **Purpose:** [Why this event exists]\n \n ### Data Management Strategy\n - **Database per Service:** [How to achieve data independence]\n - **Data Consistency:** [Eventual consistency patterns]\n - **Shared Reference Data:** [How to handle shared data]\n \n ### Cross-Cutting Concerns\n - **Authentication/Authorization:** [Approach for security]\n - **Logging and Monitoring:** [Observability strategy]\n - **Configuration Management:** [How services get configuration]\n - **API Gateway:** [Entry point and routing strategy]\n \n ### Migration Strategy\n #### Phase 1: [Initial extraction]\n - **Services to Extract:** [List of services]\n - **Migration Approach:** [Strangler fig, big bang, etc.]\n - **Risk Assessment:** [Key risks and mitigation]\n \n #### Phase 2: [Next phase]\n [Continue with additional phases]\n \n ### Architecture Quality Assessment\n - **Service Cohesion:** [How well-focused each service is]\n - **Service Coupling:** [Dependencies between services]\n - **Data Consistency:** [How data consistency is maintained]\n - **Scalability:** [Independent scaling capabilities]\n - **Fault Tolerance:** [Resilience patterns]\n \n ### Recommendations\n - **Quick Wins:** [Easy services to extract first]\n - **Complex Extractions:** [Services requiring careful planning]\n - **Technology Considerations:** [Tech stack recommendations]\n - **Operational Readiness:** [Infrastructure and tooling needs]\n ```\n\n**Guidelines:**\n- Prefer smaller, focused services over large services\n- Ensure each service can be developed and deployed independently\n- Minimize data sharing between services\n- Design for failure and resilience\n- Consider the organizational structure (Conway's Law)\n- Balance service granularity with operational complexity\n\nPlease analyze the bounded contexts and provide the microservices architecture design.\n```\n\n## Expected Output\nA comprehensive microservices architecture design with clear service boundaries, responsibilities, and migration strategy.", "variables": [], "notes": "2. **Output Format:** ``` ## Microservices Architecture Design", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/oliviasmim/ai-refactoring-resources", "path": ".github/prompts/copilot-prompts/ddd-prompt-4-microservices-design.prompt.md", "ref": "a814cd590cf77c50cbd1743352b19f6cf157569c", "url": "https://github.com/oliviasmim/ai-refactoring-resources/blob/a814cd590cf77c50cbd1743352b19f6cf157569c/.github/prompts/copilot-prompts/ddd-prompt-4-microservices-design.prompt.md", "key": "oliviasmim/ai-refactoring-resources/.github/prompts/copilot-prompts/ddd-prompt-4-microservices-design.prompt.md" } } }

ddd-prompt-4-microservices-design

About