# Microservices Decomposition

> Use when decomposing monoliths into microservices.

- Skill: `loopyluci/microservices-decomposition` (Agent Skill)
- Install (CLI): `npx skillmds@latest add loopyluci/microservices-decomposition`
- Raw SKILL.md: https://api.skillmd.com/api/skills/loopyluci/microservices-decomposition/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: LoopyLuci (https://skillmd.com/u/loopyluci)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/loopyluci/microservices-decomposition

---


# Microservices Decomposition

Decomposing monolithic applications into microservices — from bounded context mapping through service boundaries, inter-service communication, data decomposition, and migration strategies.

## When to Use

- Breaking a monolith into microservices
- Identifying service boundaries from domain analysis
- Designing inter-service communication patterns
- Migrating data from shared to per-service databases
- Managing the decomposition process safely

## Decomposition Patterns

```python
DECOMPOSITION_STRATEGIES = {
    'business_capability': 'Split by business functions (orders, payments, shipping)',
    'subdomain': 'Split by DDD subdomains (core, supporting, generic)',
    'strangler_fig': 'Gradually replace monolith pieces with new services',
    'event_storming': 'Identify aggregates and bounded contexts via workshops',
}

def identify_services(domain_events: List[str]) -> List[str]:
    """Identify candidate services from domain events."""
    # Group events by noun/entity
    services = set()
    for event in domain_events:
        words = event.split()
        # First noun after the verb is likely a service candidate
        for i, w in enumerate(words):
            if w.lower() in ('created', 'updated', 'deleted', 'submitted', 'approved'):
                if i + 1 < len(words):
                    services.add(words[i + 1].lower())
    return list(services)
```

## Common Pitfalls

1. **Distributed monolith** — services that can't be deployed independently
2. **Shared database** — services sharing a database = no real decomposition
3. **Too fine-grained** — each method as a service creates overhead chaos
4. **Wrong boundaries** — splitting along technical layers (not business domains)
5. **No data strategy** — data is the hardest part; plan per-service databases

## Verification Checklist

- [ ] Bounded contexts identified and mapped
- [ ] Services align with business capabilities
- [ ] Each service has its own data store
- [ ] Inter-service communication pattern chosen (sync/async/event)
- [ ] Strangler Fig migration plan in place
- [ ] Deployment independence verified