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