Fähigkeiten ddd-context-mapping
📦

ddd-context-mapping

Sicher

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.

Unterstützt: Claude Codex Code(CC)
📊 71 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "ddd-context-mapping". Beziehungen zwischen Checkout-, Billing- und Inventory-Contexts für eine E-Commerce-Plattform abbilden

Erwartetes Ergebnis:

  • 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

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

Erwartetes Ergebnis:

  • 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

Sicherheitsaudit

Sicher
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
Gescannte Dateien
78
Analysierte Zeilen
0
befunde
1
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude

Qualitätsbewertung

41
Architektur
100
Wartbarkeit
87
Inhalt
32
Community
100
Sicherheit
83
Spezifikationskonformität

Was du bauen kannst

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.

Probiere diese 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.

Bewährte Verfahren

  • 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

Vermeiden

  • 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

Häufig gestellte Fragen

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.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

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

Ref

main

Dateistruktur

📁 references/

📄 context-map-patterns.md

📄 SKILL.md