💻 Développement

microservices-designer

Conception et découpage d'architecture microservices.

⚡ Installation & lancement en 1 commande

Copiez-collez dans votre terminal : le skill s'installe dans ~/.claude/skills et Claude Code se lance directement dessus.

macOS / Linux

curl -fsSL https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.sh | sh -s -- microservices-designer --launch

Windows (PowerShell)

iex "& { $(iwr -useb https://raw.githubusercontent.com/khalilbenaz/claude-skills-collection/main/install.ps1) } microservices-designer -Launch"

🚀 Déjà installé ?

claude "/microservices-designer"

Ou tapez /microservices-designer dans une session Claude Code, ou décrivez simplement votre besoin — le skill se déclenche automatiquement via le skill-router.

🔑 Déclencheurs automatiques

Le skill s'active automatiquement quand votre demande contient :

microservicesdécoupagebounded contextservice meshdécomposition monolithearchitecture distribuée

📦 Installation manuelle

git clone https://github.com/khalilbenaz/claude-skills-collection.git cp -r claude-skills-collection/dev-skills/microservices-designer ~/.claude/skills/

Source : dev-skills/microservices-designer

📖 Manuel

Microservices Designer

Workflow

Analyse du domaine métier (Domain-Driven Design, bounded contexts, ubiquitous language) — identifier les sous-domaines core, supporting et generic
Identification des services (un service = un bounded context, responsabilité unique) — valider la cohésion forte et le couplage faible entre services
Définition des contrats d'API inter-services (REST, gRPC, GraphQL federation) — documenter chaque interface avec versioning et contrat de stabilité
Choix du pattern de communication (synchrone vs asynchrone, saga, choreography vs orchestration) — évaluer les besoins de cohérence et de latence
Conception de la gestion des données (database per service, event sourcing, CQRS) — éviter le partage de base de données entre services
Définition de la résilience (circuit breaker, retry, timeout, bulkhead, fallback) — chaque service doit survivre à la défaillance de ses dépendances
Observabilité (distributed tracing, centralized logging, health checks, metrics) — mettre en place correlation IDs et un stack ELK/Prometheus/Jaeger
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)