Compétences software-architecture
🏗️

software-architecture

Sûr

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.

Prend en charge: Claude Codex Code(CC)
🥉 75 Bronze
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

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ûr
v1 • 2/25/2026

All 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.

1
Fichiers analysés
81
Lignes analysées
0
résultats
1
Total des audits
Aucun problème de sécurité trouvé
Audité par: claude

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
50
Communauté
100
Sécurité
100
Conformité aux spécifications

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 la Structure de Mon Code
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.
Concevoir l'Architecture d'un Module
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.
Trouver une Meilleure Solution Bibliothèque
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.
Refactoring des Anti-Patterns
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

Foire aux questions

Qu'est-ce que Clean Architecture ?
Clean Architecture est un pattern de conception logicielle qui sépare les préoccupations en couches distinctes : entités domaine (règles métier), cas d'utilisation (règles d'application), adaptateurs d'interface (controllers, presenters), et frameworks (UI, base de données). Cette independence rend votre code testable et flexible.
Pourquoi éviter les fichiers utils et helpers ?
Les utils et helpers génériques deviennent des poubelles pour du code non lié. Ils manquent de but clair et deviennent invoquables. Les noms spécifiques au domaine comme OrderCalculator ou EmailValidator communiquent l'intention et gardent le code organisé par contexte métier.
Quand dois-je écrire du code personnalisé au lieu d'utiliser une bibliothèque ?
Écrire du code personnalisé uniquement pour la logique métier unique, les chemins critiques en performance avec des besoins spéciaux, le code sensible à la sécurité nécessitant un contrôle total, ou quand les solutions existantes ne répondent vraiment pas à vos exigences après une évaluation approfondie.
Quelles limites de taille de fichier sont recommandées ?
Garder les fonctions sous 50 lignes quand possible et les fichiers sous 200 lignes. Décomposer les composants plus longs en pièces plus petites et concentrées. Si le code ne peut pas être réutilisé ailleurs, le garder dans le même fichier jusqu'à ce que le split devienne nécessaire pour la maintenabilité.
Comment cette skill diffère-t-elle des assistants de codage généraux ?
Cette skill se concentre spécifiquement sur les décisions architecturales et l'organisation du code plutôt que sur la syntaxe ou les détails d'implémentation. Elle guide la structure de haut niveau, les design patterns et la maintenabilité plutôt que d'écrire des algorithmes spécifiques ou de corriger des bugs.
Puis-je utiliser cette skill pour n'importe quel langage de programmation ?
Oui. Les principes architecturaux (Clean Architecture, DDD, séparation des préoccupations) s'appliquent à tous les langages. Cependant, les détails d'implémentation varient entre les langages et frameworks, donc adaptez les recommandations à votre stack technologique spécifique.

Détails du développeur

Structure de fichiers

📄 SKILL.md