software-architecture
Construire une Architecture Logicielle Évolutive
Également disponible depuis: Doyajin174,Chemiseblanc
Arrêtez de réinventer la wheel avec des utilitaires et helpers personnalisés. Cette skill enseigne les principes de Clean Architecture et du Domain-Driven Design pour vous aider à écrire du code maintenable et évolutif.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "software-architecture". Review this UserService class for architectural issues: [ UserService class with database queries, API calls, and UI rendering all mixed together ]
Résultat attendu:
Problèmes Architecturaux Détectés : 1) Préoccupations mélangées - les requêtes database appartiennent à la couche Repository, 2) Le rendu UI devrait être dans un composant view séparé, 3) Les appels API devraient être dans un service dédié. Refactorisation Recommandée : Diviser en UserRepository (données), UserService (logique métier), et UserView (présentation).
Utilisation de "software-architecture". I need to implement payment processing. Should I build my own or use a library?
Résultat attendu:
Recommandation : Utiliser Stripe ou Paddle au lieu de construire un traitement de paiement personnalisé. Ces services gèrent la conformité PCI, la facturation récurrente, les webhooks et les cas edge qui prendraient des mois à construire vous-même. Ne considérer une implémentation personnalisée que si vous avez des exigences très uniques que les solutions existantes ne peuvent pas satisfaire.
Utilisation de "software-architecture". Design a module for order processing in an e-commerce app
Résultat attendu:
Architecture Recommandée (DDD) : 1) Entité Order (domaine) : Order, OrderItem, OrderStatus. 2) Repositories : OrderRepository, InventoryRepository. 3) Services : OrderService (placeOrder, cancelOrder), PaymentService (processPayment), InventoryService (reserveItems). 4) Anti-patterns à éviter : OrderController faisant de la logique métier, requêtes database dans les controllers, classe OrderUtils générique.
Audit de sécurité
SûrAll static analysis findings are false positives. Detected 'backtick execution' patterns are markdown code emphasis formatting for library names and file examples. 'Weak cryptographic algorithm' detections are references to 'Clean Architecture' design pattern, not cryptography. 'System reconnaissance' patterns match legitimate software development guidance. This skill contains no executable code and provides educational architecture guidance only.
Score de qualité
Ce que vous pouvez construire
Architecture de Projet Greenfield
Démarrer un nouveau projet et établir une base architecturale solide dès le premier jour
Refactoring de Code Hérité
Améliorer la qualité du code dans une base de code existante en appliquant les principes de clean architecture
Standards de Code Review
Établir des lignes directrices architecturales cohérentes pour les code reviews et les pull requests de l'équipe
Essayez ces prompts
Revoir ce composant de code pour des problèmes architecturaux. Vérifier : le nommage générique (utils/helpers), la logique métier mélangée à l'UI, les fichiers de plus de 200 lignes, et les fonctions de plus de 50 lignes. Suggérer des améliorations suivant les principes de Clean Architecture.
J'ai besoin de construire un module [feature]. Concevoir l'architecture suivant les principes DDD. Suggérer des noms spécifiques au domaine pour les entités, services et repositories. Définir des limites claires et la séparation des préoccupations.
J'ai besoin d'implémenter une fonctionnalité [feature]. Rechercher des bibliothèques ou services existants qui résolvent ce problème. Évaluer les options basées sur : le statut de maintenance, l'adoption par la communauté, la qualité de la documentation, et l'adéquation à mes exigences.
Analyser cette base de code pour des anti-patterns architecturaux : syndrome NIH (implémentations personnalisées au lieu de bibliothèques), noms de fichiers génériques, mauvaise séparation des préoccupations, et nesting profond. Fournir des recommandations de refactoring spécifiques avec des exemples.
Bonnes pratiques
- Rechercher des bibliothèques et services existants avant d'écrire du code personnalisé pour réduire la charge de maintenance
- Utiliser des noms spécifiques au domaine comme OrderCalculator et UserAuthenticator au lieu de utils ou helpers génériques
- Garder la logique métier indépendante des frameworks et séparée des composants UI
- Appliquer le pattern early return pour réduire le nesting et améliorer la lisibilité du code
Éviter
- Créer des fichiers utils.js ou helpers.ts avec des fonctions non liées au lieu de modules spécifiques au domaine
- Mélanger la logique métier avec les composants UI ou mettre des requêtes database directement dans les controllers
- Construire une authentification personnalisée, une gestion d'état ou une validation de formulaire quand des bibliothèques établies existent
- Nommer les fichiers ou modules de manière générique (common, shared, misc) sans but de domaine clair