Compétences ddd-context-mapping
📦

ddd-context-mapping

Sûr

Bounded Context-Beziehungen mit DDD-Patterns abbilden

Domain-Driven Design Integration wird komplex, wenn mehrere Bounded Contexts interagieren. Dieser Skill definiert klare Verträge und Anti-Corruption-Layer zwischen Contexts unter Verwendung bewährter DDD-Patterns.

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". Beziehungen zwischen Checkout-, Billing- und Inventory-Contexts für eine E-Commerce-Plattform abbilden

Résultat attendu:

  • Context Map: Checkout-Billing (Customer-Supplier, Billing besitzt Vertrag)
  • Context Map: Checkout-Inventory (Partnership, geteilte Vertragsverantwortlichkeit)
  • ACL erforderlich an Billing-Grenze zur Übersetzung von Zahlungsbegriffen
  • Coupling-Risiko: Inventory-Verfügbarkeitsänderungen beeinflussen Checkout-Flow

Utilisation de "ddd-context-mapping". Integration zwischen neuem Order-Context und Legacy-ERP-System entwerfen

Résultat attendu:

  • Pattern: Anti-Corruption-Layer zwischen Order und ERP
  • Order-Context definiert kanonisches Order-Modell
  • ACL übersetzt ERP-Terminologie in Order-Ubiquitous-Language
  • Contract-Tests validieren ACL-Verhalten für alle ERP-Szenarien

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

Microservices-Integrationsplanung

Abbilden, wie Checkout-, Billing-, Inventory- und Fraud-Contexts integriert werden, bevor Servicegrenzen implementiert werden.

Legacy-System-Migration

Definieren von Anti-Corruption-Layern bei der Integration neuer Domänen mit bestehenden monolithischen Systemen.

Cross-Team-Vertragsdefinition

Klärung von Upstream- und Downstream-Ownership, um Domain-Leakage und unklare Verantwortlichkeiten zu verhindern.

Essayez ces prompts

Basis-Context-Mapping 
Analysieren Sie meine Domäne mit diesen Bounded Contexts: [list contexts]. Identifizieren Sie die Beziehungen zwischen jedem Paar und empfehlen Sie geeignete Context Mapping Patterns aus DDD.
Anti-Corruption-Layer-Design 
Ich muss mit [external system/context] integrieren. Entwerfen Sie einen Anti-Corruption-Layer, der deren Modell in meine Ubiquitous Language übersetzt und gleichzeitig meinen Domänenkern schützt.
Contract-Ownership-Matrix 
Erstellen Sie eine Contract-Ownership-Matrix für diese Context-Paare: [list pairs]. Definieren Sie, wer jeden Vertrag besitzt, welche Übersetzung erforderlich ist und das Coupling-Risikoniveau.
Failure-Mode-Analyse 
Für die [upstream] zu [downstream] Context-Integration mit [pattern] identifizieren Sie Failure Modes, definieren Sie Fallback-Verhalten und etablieren Sie eine Versionierungsrichtlinie.

Bonnes pratiques

  • Anti-Corruption-Layer-Code an Domänengrenzen belassen, nicht im Domänenkern
  • Contract-Tests hinzufügen, um zu verifizieren, dass übersetztes Verhalten den erwarteten Semantiken entspricht
  • Context-Maps überprüfen, wenn Team-Ownership oder Geschäftsdomänen sich ändern

Éviter

  • Erlauben, dass Downstream-Contexts direkt von Upstream-internen Modellen abhängen
  • Erstellen von Shared Kernels zwischen Contexts, die unabhängig bleiben sollten
  • Überschlagen von Übersetzungsschichten bei Integration mit externen oder Legacy-Systemen

Foire aux questions

Wann sollte ich einen Anti-Corruption-Layer gegenüber einem Conformist-Pattern verwenden?
Verwenden Sie ACL, wenn das Upstream-Modell mit Ihrer Ubiquitous Language in Konflikt steht oder bei Integration mit externen Systemen. Verwenden Sie Conformist, wenn das Upstream-Modell stabil ist und mit Ihren Anforderungen übereinstimmt.
Wie viele Bounded Contexts sollte ein typisches System haben?
Es gibt keine feste Anzahl. Contexts entstehen aus Geschäftsdomänen und Teamgrenzen. Beginnen Sie mit wichtigen Geschäftsfähigkeiten und teilen Sie auf, wenn Sie widersprüchliche Ubiquitous Languages erkennen.
Kann ein Context mehrere Beziehungspatterns mit einem anderen Context haben?
Ja, verschiedene Aggregates innerhalb von Contexts können unterschiedliche Patterns verwenden. Dokumentieren Sie jede Beziehung separat, um Verwirrung zu vermeiden.
Was ist ein Shared Kernel und wann sollte ich ihn vermeiden?
Shared Kernel ist eine Teilmenge des Domänenmodells, die von zwei Teams geteilt wird. Vermeiden Sie dies, wenn Contexts sich unabhängig entwickeln müssen oder wenn der Team-Koordinationsaufwand zu hoch wird.
Wie gehe ich mit Versionierung um, wenn sich Context-Verträge ändern?
Etablieren Sie eine Versionierungsrichtlinie von Anfang an. Unterstützen Sie Abwärtskompatibilität während Übergangsperioden. Verwenden Sie Contract-Tests, um Breaking Changes vor dem Deployment zu erkennen.
Funktioniert dieser Skill auch für monolithische Anwendungen?
Ja, Bounded Contexts können innerhalb von Monolithen als modulare Grenzen existieren. Context Mapping hilft bei der Planung zukünftiger Service-Extraktion und verhindert Domain-Leakage über Module hinweg.

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