architecture
Cadre de prise de décision architecturale
Cette compétence aide les équipes à prendre de meilleures décisions architecturales grâce à l'analyse structurée des compromis et à la documentation ADR. Elle fournit des arbres de décision, des conseils sur les patterns et des modèles pour documenter les choix d'architecture avec leur justification.
تنزيل ZIP المهارة
رفع في Claude
اذهب إلى Settings → Capabilities → Skills → Upload skill
فعّل وابدأ الاستخدام
اختبرها
استخدام "architecture". Aidez-moi à planifier l'architecture pour une application e-commerce MVP avec 1 développeur
النتيجة المتوقعة:
Pour un MVP avec un développeur solo, je recommande : structure monolithe avec Next.js, Prisma pour l'accès aux données, authentification JWT, base de données PostgreSQL, Stripe pour les paiements. Compromis : mise à l'échelle indépendante limitée, possibilité d'extraire des services plus tard lorsque justifié.
استخدام "architecture". Créer un ADR pour choisir PostgreSQL plutôt que MongoDB
النتيجة المتوقعة:
Modèle ADR : Contexte - besoin de données transactionnelles fiables. Options considérées : PostgreSQL (ACID, requêtes complexes) vs MongoDB (flexible, mise à l'échelle horizontale). Décision : PostgreSQL. Justification : le e-commerce nécessite l'intégrité transactionnelle. Compromis acceptés : schéma moins flexible initialement.
التدقيق الأمني
آمنAll static findings are false positives. The skill is a documentation guide for architectural decision-making. Detected patterns are markdown formatting (backticks), authentication standards (SAML, JWT), and normal decision-making terms (validate). No actual security risks identified.
مشكلات متوسطة المخاطر (1)
مشكلات منخفضة المخاطر (3)
درجة الجودة
ماذا يمكنك بناءه
Planification de l'architecture d'un nouveau projet
Lors du démarrage d'un nouveau projet, utilisez cette compétence pour déterminer l'architecture appropriée en fonction de la taille de l'équipe, des exigences d'échelle et des contraintes de délai.
Documentation des décisions d'architecture
Lors de choix architecturaux significatifs, utilisez les modèles ADR pour enregistrer le contexte, les options envisagées, la justification de la décision et les compromis acceptés.
Conseil pour la sélection de patterns
Lorsque vous hésitez sur le pattern d'architecture à utiliser, consultez les arbres de décision pour évaluer les compromis entre des options comme monolithe vs microservices, REST vs GraphQL.
جرّب هذه الموجهات
Aidez-moi à définir l'architecture pour un nouveau [project type] avec [team size] développeurs, ciblant [user scale] utilisateurs, avec un délai de [timeline]. Le budget est [budget constraint]. Utilisez la compétence architecture pour guider cette décision.
Générez un ADR pour choisir [technology/pattern] plutôt que des alternatives. Le contexte implique [problem description]. Considérez ces contraintes : [list constraints]. Utilisez le cadre d'analyse des compromis de la compétence architecture.
Aidez-moi à choisir entre l'architecture microservices et monolithe pour un [project description] avec [team size] développeurs. Quels sont les compromis ? Quand chaque approche est-elle justifiée ?
Quel pattern d'accès aux données recommanderiez-vous pour un [project type] avec des besoins d'accès aux données de niveau [complexity level] ? Considérez : la taille de l'équipe est [size], les exigences de test sont [level], les sources de données incluent [sources].
أفضل الممارسات
- Commencez par l'architecture la plus simple qui répond aux besoins actuels et ajoutez de la complexité uniquement lorsque cela s'avère nécessaire
- Documentez toujours les compromis - chaque choix d'architecture a des coûts et des bénéfices qui doivent être explicites
- Utilisez les ADR pour capturer non seulement ce qui a été décidé mais pourquoi, y compris les contraintes qui ont influencé le choix
- Considérez l'expertise de l'équipe lors du choix des patterns - le meilleur pattern est inutile si l'équipe ne peut pas le maintenir
تجنب
- Microservices prématurés - diviser les services avant que la taille de l'équipe ou l'échelle ne justifie la complexité
- Sur-abstraction avec l'architecture Clean/Hexagonal lorsque simple CRUD suffirait
- Choisir CQRS ou Event Sourcing sans preuve de performance en lecture/écriture montrant un bénéfice
- Ignorer les compromis - chaque choix architectural a des coûts qui doivent être reconnus