Compétences ddd-context-mapping
📦

ddd-context-mapping

Sûr

Mapper les relations de contexte borné avec les patterns DDD

L'intégration Domain-Driven Design devient complexe lorsque plusieurs contextes bornés interagissent. Cette compétence définit des contrats clairs et des couches anti-corruption entre les contextes en utilisant des patterns DDD éprouvés.

Prend en charge: Claude Codex Code(CC)
🥉 74 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 "ddd-context-mapping". Cartographier les relations entre les contextes Checkout, Billing et Inventory pour une plateforme e-commerce

Résultat attendu:

  • Context Map: Checkout-Billing (Customer-Supplier, Billing owns contract)
  • Context Map: Checkout-Inventory (Partnership, shared contract ownership)
  • ACL required at Billing boundary to translate payment terms
  • Coupling risk: Inventory availability changes affect Checkout flow

Utilisation de "ddd-context-mapping". Concevoir l'intégration entre le nouveau contexte Order et le système ERP hérité

Résultat attendu:

  • Pattern: Anti-Corruption Layer between Order and ERP
  • Order context defines canonical Order model
  • ACL translates ERP terminology to Order ubiquitous language
  • Contract tests validate ACL behavior for all ERP scenarios

Audit de sécurité

Sûr
v1 • 2/24/2026

Static analysis flagged markdown backticks as shell commands and weak cryptography patterns. All findings are FALSE POSITIVES - the skill contains only documentation and reference material with no executable code, network calls, or filesystem operations. Safe for publication.

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

Score de qualité

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

Ce que vous pouvez construire

Planification d'intégration de microservices

Cartographier comment les contextes Checkout, Billing, Inventory et Fraud s'intègrent avant d'implémenter les limites de services.

Migration de système hérité

Définir des couches anti-corruption lors de l'intégration de nouveaux domaines avec les systèmes monolithiques existants.

Définition de contrats inter-équipes

Clarifier la propriété en aval et en amont pour éviter les fuites de domaine et les responsabilités floues.

Essayez ces prompts

Cartographie de contexte basique 
Analysez mon domaine avec ces contextes bornés : [list contexts]. Identifiez les relations entre chaque paire et recommandez les modèles de cartographie de contexte appropriés de DDD.
Conception de couche anti-corruption 
J'ai besoin de m'intégrer avec [external system/context]. Concevez une couche anti-corruption qui traduit leur modèle en ma langue ubiquite tout en保护ant mon domaine core.
Matrice de propriété de contrats 
Créez une matrice de propriété de contrats pour ces paires de contextes : [list pairs]. Définissez qui possède chaque contrat, quelle traduction est nécessaire, et le niveau de risque de couplage.
Analyse des modes de défaillance 
Pour l'intégration du contexte [upstream] vers [downstream] en utilisant le modèle [pattern], identifiez les modes de défaillance, définissez les comportements de repli et établissez une politique de versioning.

Bonnes pratiques

  • Gardez le code de la couche anti-corruption aux frontières du domaine, pas à l'intérieur du core du domaine
  • Ajoutez des tests de contrat pour vérifier que le comportement traduit correspond à la sémantique attendue
  • Revoyez les cartes de contexte lorsque la propriété de l'équipe ou les domaines métier changent

Éviter

  • Permettre aux contextes aval de dépendre directement des modèles internes en amont
  • Créer des noyaux partagés entre les contextes qui devraient rester indépendants
  • Ignorer les couches de traduction lors de l'intégration avec des systèmes externes ou hérités

Foire aux questions

Quand dois-je utiliser une couche anti-corruption versus un modèle Conformiste ?
Utilisez ACL lorsque le modèle en amont entre en conflit avec votre langue ubiquite ou lors de l'intégration avec des systèmes externes. Utilisez Conformiste lorsque le modèle en amont est stable et s'aligne avec vos besoins.
Combien de contextes bornés un système typique devrait-il avoir ?
Il n'y a pas de nombre fixe. Les contextes émergent des domaines métier et des limites d'équipe. Commencez par les capacités métier majeures et divisez lorsque vous détectez des langues ubiquites conflictuelles.
Un contexte peut-il avoir plusieurs modèles de relation avec un autre contexte ?
Oui, différents agrégats au sein des contextes peuvent utiliser différents modèles. Documentez chaque relation séparément pour éviter la confusion.
Qu'est-ce qu'un Shared Kernel et quand dois-je l'éviter ?
Shared Kernel est un sous-ensemble du modèle de domaine partagé par deux équipes. Évitez-le lorsque les contextes ont besoin d'une évolution indépendante ou lorsque la surcharge de coordination d'équipe devient trop élevée.
Comment gérer le versioning lorsque les contrats de contexte changent ?
Établissez une politique de versioning dès le début. Supportez la rétrocompatibilité pendant les périodes de transition. Utilisez des tests de contrat pour détecter les changements cassants avant le déploiement.
Cette compétence fonctionne-t-elle pour les applications monolithiques ?
Oui, les contextes bornés peuvent exister au sein de monolithes comme frontières modulaires. La cartographie de contexte aide à planifier l'extraction future de services et empêche les fuites de domaine entre les modules.

Détails du développeur

Auteur

sickn33

Licence

MIT

Dépôt

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/ddd-context-mapping

Réf

main

Structure de fichiers

📁 references/

📄 context-map-patterns.md

📄 SKILL.md