Marco Rossi·
Broke our monolith into DDD contexts with a choreography saga for checkout and a strangler-fig plan
Transforms a monolithic application blueprint into a well-designed microservices architecture with clear service boundaries and inter-service communication patterns.
Microservices Decomposition Strategy
Act as a Domain-Driven Design expert and Microservices Architect. Help me decompose a monolithic application into microservices.
**Application Domain**: {{application_domain}} (e.g., e-commerce, healthcare, fintech)
**Current Monolith Description**: {{current_monolith_description}} (key modules, features, and pain points)
**Team Structure**: {{team_structure}} (number of teams, sizes, and expertise areas)
**Constraints**: {{constraints}} (e.g., shared database, compliance, latency requirements)
Provide the following:
1. **Bounded Contexts Map** - Identify all bounded contexts using DDD principles with clear ubiquitous language for each
2. **Service Decomposition** - Each microservice with: name, responsibility, owned data, APIs exposed, and dependencies
3. **Service Communication Matrix** - Table showing which services talk to which, using what pattern (sync/async), and frequency
4. **Database Strategy** - Database-per-service design with schema boundaries and data ownership rules
5. **Saga Patterns** - Identify distributed transactions and recommend choreography vs orchestration for each
6. **API Gateway Design** - Routing rules, aggregation points, rate limiting strategy per service
7. **Deployment Topology** - Independent deployability analysis and CI/CD pipeline per service
8. **Anti-Corruption Layers** - Where to place ACLs when integrating with legacy or external systems
9. **Migration Phases** - Step-by-step strangler fig migration plan from monolith to microservices
10. **Team Assignment** - Which team owns which service based on Conway's Law
Use the words 'must', 'should', 'could' to indicate priority level for each recommendation.
Ergebnisse
## Monolith Decomposition — e-commerce platform (DDD)
Decomposed the Rails monolith into services along bounded-context seams. Priority tags: **must** (do first), **should** (next), **could** (later).
**Bounded contexts identified:**
```
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ Catalog │ │ Ordering │ │ Payments │
│ products, │ │ cart, order, │ │ charge, │
│ inventory │ │ fulfillment │ │ refund │
└─────────────┘ └──────────────┘ └─────────────┘
│ │ │
┌────▼─────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ Identity │ │ Notification│ │ Shipping │
└──────────┘ └─────────────┘ └─────────────┘
```
**Service split (excerpt):**
| Service | Owns | Exposes | Talks to |
|---------|------|---------|----------|
| Ordering | orders, line items | REST + emits `OrderPlaced` | Catalog (sync), Payments (async) |
| Payments | charges, refunds | gRPC | emits `PaymentCaptured` |
| Inventory | stock levels | REST | consumes `OrderPlaced` |
**Must — database-per-service:** the shared `orders` + `inventory` tables are the worst coupling. Split them first; each service owns its schema, no cross-service joins.
**Distributed transaction (checkout) — use a saga, choreography style:**
```
OrderPlaced ─▶ Payments.charge ─▶ PaymentCaptured ─▶ Inventory.reserve
│ fail │ fail
▼ ▼
OrderCancelled ◀───────── StockUnavailable (compensating events)
```
**Should — strangler-fig migration:** route `/checkout` through an API gateway that sends traffic to the new Ordering service while everything else still hits the monolith; cut over context by context. **Could — anti-corruption layer** around the legacy tax engine so its quirky model never leaks into the new domain. **Team mapping (Conway's Law):** the payments team owns Payments end to end so service boundaries match team boundaries.
Modell: Claude Opus 4
11 Likes3 SavesScore: 8