domain-driven-design
Appliquer la Conception Pilotée par le Domaine avec Guidance IA
Les projets logiciels complexes nécessitent une modélisation structurée du domaine, mais savoir quand et comment appliquer la DDD est un défi. Cette compétence vous aide à évaluer la viabilité de la DDD, planifier l'architecture stratégique et router vers des compétences d'implémentation spécialisées.
下載技能 ZIP
在 Claude 中上傳
前往 設定 → 功能 → 技能 → 上傳技能
開啟並開始使用
測試它
正在使用「domain-driven-design」。 Utilisez @domain-driven-design pour évaluer si notre plateforme e-commerce devrait adopter la DDD complète
預期結果:
Résultats de la vérification de viabilité : Votre plateforme e-commerce satisfait probablement plusieurs critères en raison de règles métier complexes (tarification, inventaire), de plusieurs équipes et de contrats d'intégration. Recommandation : Adoptez d'abord la DDD stratégique avec des contextes délimités pour les Commandes, l'Inventaire, les Paiements et la Livraison.
正在使用「domain-driven-design」。 Aidez-nous à planifier les artefacts stratégiques pour notre domaine de santé
預期結果:
Livrables stratégiques pour la santé : (1) Carte des sous-domaines identifiant les domaines clés comme la Gestion des Patients, la Planification, la Facturation ; (2) Carte des contextes délimités avec les limites de conformité HIPAA ; (3) Glossaire de langage ubiquitaire pour la terminologie médicale ; (4) ADRs pour les décisions critiques.
安全審計
安全Static analysis flagged 19 potential issues including external_commands and weak cryptographic algorithms. Manual review confirms these are false positives: the @ mentions in skill references were mistaken for backtick execution, and the word 'design' was incorrectly flagged as cryptographic. This is a documentation-only skill containing no executable code, network requests, or file system operations. All findings dismissed as false positives.
品質評分
你能建構什麼
Session de Planification Architecturale
À utiliser au début d'un nouveau projet pour déterminer si la DDD est appropriée et planifier les limites des contextes délimités.
Guide de Décision de Refactoring
Évaluer un monolithe existant pour identifier les limites des sous-domaines et planifier l'adoption incrémentale de la DDD.
Outil de Coordination d'Équipe
Établir un langage ubiquitaire partagé et des limites de propriété claires entre plusieurs équipes.
試試這些提示
Utilisez @domain-driven-design pour évaluer si nous devrions adopter la DDD complète pour notre [description du projet]. Exécutez la vérification de viabilité et expliquez quels critères sont satisfaits.
Appliquez @domain-driven-design pour nous aider à identifier les sous-domaines et contextes délimités pour notre [domaine métier]. Listez les artefacts stratégiques que nous devrions produire en premier.
Nous avons décidé d'adopter la DDD pour [contexte délimité spécifique]. Utilisez @domain-driven-design pour nous router vers les prochaines compétences dont nous avons besoin et listez les livrables tactiques pour cette semaine.
Notre domaine nécessite une auditabilité et un historique des événements. Utilisez @domain-driven-design pour nous aider à décider si l'event sourcing est approprié et quelles compétences utiliser pour l'implémentation.
最佳實務
- Commencez par la DDD stratégique avant de plonger dans les détails d'implémentation tactique
- Utilisez la vérification de viabilité pour éviter le sur-ingénierie des systèmes simples
- Produisez des artefacts explicites à chaque étape pour garantir une progression mesurable
- Routez vers des compétences spécialisées plutôt que d'essayer de tout gérer avec un seul prompt
避免
- Appliquer la DDD complète à des applications CRUD simples sans règles métier complexes
- Sauter la modélisation stratégique et passer directement à la conception des entités
- Créer des contextes délimités basés sur des couches techniques au lieu de capacités métier
- Utiliser la DDD comme justification pour le sur-ingénierie sans complexité de domaine claire