@microservices-architectLe décompositeur — et celui qui dit non quand il faut
Maifady est un plugin Claude Code 100% gratuit avec 30 agents IA — @microservices-architect analyse ton monolithe et te propose une décomposition en services seulement si elle est justifiée. Sinon, il recommande un modular monolith. Bounded contexts DDD, sagas, outbox pattern, anti-patterns évités.
Le problème qu'il résout
Ton monolithe a 8 ans, 200k lignes. Quelqu'un dans l'équipe te dit "il faut migrer en microservices". Tu n'es pas sûr. Tu sais que la moitié des SaaS qui ont fait cette migration ont fini avec un distributed monolith (services qui ne peuvent pas être déployés indépendamment, latence cumulée, ops infernale).
@microservices-architect est l'agent qui te pousse à NE PAS faire de microservices quand c'est le mauvais choix. Et qui te dit comment faire si c'est le bon.
Comment il bosse
- Évalue d'abord si tu devrais STAYING monolithique : équipe < 8 devs, pas de scaling pain, pas de besoin de déploiement indépendant, ops pas mature.
- Si pushback : propose un modular monolith (modules avec frontières claires, prêt à extraire plus tard).
- Si décomposition justifiée : identifie les bounded contexts (DDD).
- Mappe data ownership : UN service possède les writes d'une table.
- Inter-service comms : événements async (Kafka, Redis Streams, SNS+SQS) > sync REST/gRPC.
- Plan de migration en strangler fig, pas big-bang.
- Flag les anti-patterns : distributed monolith, shared DB, chatty interfaces, sync chains.
Exemple concret
Tu tapes
›@microservices-architect analyse mon repo. Rester monolithique ou découper ? Équipe : 6 devs. Pas de scaling pain. 50k MAU.
Tu obtiens
## Recommandation
**Reste modular monolith.**
## Pourquoi
- < 8 devs → coûts ops microservices > bénéfices.
- Aucun pain de scaling actuel.
- Migrer maintenant = ralentir 6 mois pour résoudre un problème inexistant.
## Plan : Modular monolith
1. Découpe en modules avec frontières claires (dossiers + namespaces).
2. Interdis les imports cross-module sauf via API explicite.
3. Si plus tard scaling pain, extraire = facile.
## Quand reconsidérer
- > 8 devs avec friction de coordination
- Un module a un scaling pain CPU/mémoire mesurable
- Besoin tech stack différent pour un module (ex: Go pour temps réel)
Pourquoi tu vas l'aimer
Dit non quand il faut
Pas un "yes-man" qui dit ce que tu veux entendre. Te pousse à reconsidérer si c'est le mauvais moment.
Bounded contexts DDD
Découpe par business, pas par couche technique. Évite les services anémiques.
Strangler fig
Migration en slices. Extraire d'abord le module le moins risqué et le plus à valeur.
Anti-patterns flaggés
Distributed monolith, shared DB, sync chains de 5 services — détectés et évités.
Quand l'utiliser
✅ Idéal pour
- Pression interne pour microservices ("ça va scale !")
- Monolithe vraiment trop gros pour l'équipe (> 500k lignes, > 10 devs)
- Module spécifique avec scaling pain mesurable
- Besoin de stack différent pour un domaine (ex: ML en Python)
⚠️ Pas adapté quand
- Petit projet personnel / startup early stage
- Équipe < 5 devs — le coût microservices > bénéfices
- Aucun pain mesurable — résoudre un problème qu'on n'a pas
Combine avec ces agents
Questions fréquentes
Pourquoi push back si fort sur les microservices ?
Parce que c'est une décision qui ralentit l'équipe pendant 6-12 mois et augmente massivement les coûts ops. La plupart des SaaS qui le font tôt regrettent. La règle : start with a modular monolith, extract when there's measurable pain.
Quelle messagerie recommande-t-il ?
Selon le besoin : Kafka pour event streaming gros volume, RabbitMQ pour task queues, Redis Streams pour léger, SNS+SQS sur AWS. Pour event-driven : outbox pattern (transaction DB + event publié atomiquement).