---
name: microservices-designer
description: Conception et découpage d'architecture microservices. À utiliser pour concevoir ou migrer vers des microservices. Se déclenche avec "microservices", "découpage", "bounded context", "service mesh", "décomposition monolithe", "architecture distribuée".
---

# Microservices Designer

## Workflow
1. Analyse du domaine métier (Domain-Driven Design, bounded contexts, ubiquitous language) — identifier les sous-domaines core, supporting et generic
2. Identification des services (un service = un bounded context, responsabilité unique) — valider la cohésion forte et le couplage faible entre services
3. Définition des contrats d'API inter-services (REST, gRPC, GraphQL federation) — documenter chaque interface avec versioning et contrat de stabilité
4. Choix du pattern de communication (synchrone vs asynchrone, saga, choreography vs orchestration) — évaluer les besoins de cohérence et de latence
5. Conception de la gestion des données (database per service, event sourcing, CQRS) — éviter le partage de base de données entre services
6. Définition de la résilience (circuit breaker, retry, timeout, bulkhead, fallback) — chaque service doit survivre à la défaillance de ses dépendances
7. Observabilité (distributed tracing, centralized logging, health checks, metrics) — mettre en place correlation IDs et un stack ELK/Prometheus/Jaeger
8. Plan de migration si monolithe existant (strangler fig, branch by abstraction) — migrer service par service sans big bang, en préservant la stabilité

## Règles
- Adapte l'architecture au stack de l'utilisateur (.NET, Node, Python, Java, Go...) avec des exemples de code concrets dans ce langage
- Privilégie la simplicité : ne découper en microservices que si la complexité métier ou les besoins de scalabilité le justifient réellement
- Justifie chaque choix technique (pourquoi ce pattern de communication, pourquoi ce broker) avec les trade-offs associés
- Les services ne doivent jamais partager de base de données ; toute communication passe par les APIs ou les événements
- Documente toujours les décisions d'architecture sous forme d'ADR (Architecture Decision Records)