microservices-decomposition
# Microservices Decomposition Claude Code Skill This skill produces a complete microservices decomposition design grounded in Domain-Driven Design principles, delivering bounded context maps, service inventory tables, communication pattern decisions, data ownership matrices, migration roadmaps, and risk registers. Use it when decomposing a monolith into services, defining service boundaries for a new system, designing migration strategies, or aligning organizational structure to service ownership.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/microservices-decomposition && cp -r /tmp/microservices-decomposition/plugins/pm-engineering/skills/microservices-decomposition ~/.claude/skills/microservices-decompositionSKILL.md
# Microservices Decomposition Produce a complete microservices decomposition design for a system — whether decomposing an existing monolith or designing service boundaries for a new system. Ground the decomposition in Domain-Driven Design (DDD) concepts: identify bounded contexts first, then derive service boundaries from them. Include communication pattern decisions (sync vs. async, event vs. RPC), data ownership rules, and a pragmatic migration plan if decomposing a monolith. Conway's Law is real — include an organizational alignment section. The deliverable should be specific enough that a team can begin implementation, not an abstract architectural diagram. ## Required Inputs Ask for these if not already provided: - **System or domain description** — what the system does, its core domain, and the key business processes it supports - **Current architecture** — monolith (describe the tech stack and rough module structure), partial services (list existing services), or greenfield - **Team structure** — number of teams, team names if known, and approximate team sizes; this drives service ownership - **Performance and scalability requirements** — any specific SLAs, load characteristics, or scaling constraints per domain area - **Migration constraints** — what cannot be rewritten all at once, hard deadlines, zero-downtime requirements, budget constraints - **Integration points** — external systems, third-party APIs, or legacy systems that cannot be changed If decomposing a monolith, also ask for: approximate codebase size, what is most painful to change today, and where the team experiences the most coupling-related friction. ## Output Format --- # Microservices Decomposition: [System Name] **Author:** [Name / Team] **Date:** [Date] **Architecture type:** [Monolith decomposition / New system design] **Current state:** [One sentence describing what exists today] **Target state:** [One sentence describing the desired end state] --- ## 1. Domain Analysis ### Core Domain [One paragraph: what is the core domain of this system? What does the business fundamentally do? What gives it competitive differentiation? The core domain gets the most investment and the cleanest service boundaries.] ### Domain Map List every significant subdomain before assigning service boundaries. Classify each subdomain: | Subdomain | Type | Description | Current Location in Monolith | |-----------|------|-------------|------------------------------| | [Subdomain, e.g., Order Management] | Core | [What it does and why it matters] | [Module/package name or "new"] | | [Subdomain, e.g., Inventory] | Core | [Description] | [Location] | | [Subdomain, e.g., Notifications] | Supporting | [Description] | [Location] | | [Subdomain, e.g., Billing] | Supporting | [Description] | [Location] | | [Subdomain, e.g., Reporting] | Generic | [Description — candidates for off-the-shelf solutions] | [Location] | | [Subdomain, e.g., User Auth] | Generic | [Description] | [Location] | **Subdomain types:** Core = competitive differentiation, build with care; Supporting = necessary but not differentiating, build pragmatically; Generic = commodity, buy or use open source. --- ## 2. Bounded Context Map (ASCII) ``` ┌─────────────────────────────────────────────────────────────────┐ │ [System Name] │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ [Context A] │ │ [Context B] │ │ │ │ │─ ─►│ │ │ │ │ [key concepts] │ │ [key concepts] │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ │ │ │ │ event │ sync │ │ ▼ ▼ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ [Context C] │ │ [Context D] │ │ │ │ │ │ │ │ │ │ [key concepts] │ │ [key concepts] │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ │ │ ┌────────┘ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ [Context E] │ │ │ │ [key concepts] │ │ │ └──────────────────┘ │ │ │ │ External: [Third-party system] ──► [Context that owns it] │ └─────────────────────────────────────────────────────────────────┘ Legend: ──► sync call - -► async event ═══ shared kernel ``` Render this map using the actual bounded contexts derived from the domain analysis. Place contexts that communicate frequently closer together. Label relationship types on arrows. ### Context Relationships | Upstream Context | Downstream Context | Relationship Type | Integration Pattern | |-----------------|-------------------|------------------|---------------------| | [Context A] | [Context B] | Customer-Supplier | REST API call | | [Context B] | [Context C] | Published Language | Domain events via message bus | | [Context X] | [Context Y] | Conformist | [Downstream conforms to upstream's model] | | [Context X] | [Context Y] | Anti-Corruption Layer | [ACL translates upstream model to local model] | --- ## 3. Proposed Service Inventory | Service Name | Bounded Context | Core Responsibility | Team Owner | Tech Stack | Priority | |-------------|----------------|--------------------|-----------|-----------|---------| | [s
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.