Fähigkeiten ddd-strategic-design
📦

ddd-strategic-design

Sicher

Domänengrenzen mit DDD Strategic Design abbilden

Diese Skill hilft Ihnen, strategische Artefakte des Domain-Driven Design wie Subdomänen, Bounded Contexts und Ubiquitous Language zu erstellen, um klare Domänengrenzen und ein gemeinsames Verständnis mit Domänenexperten zu schaffen.

Unterstützt: Claude Codex Code(CC)
🥉 74 Bronze
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-strategic-design". Nutze @ddd-strategic-design, um unsere E-Commerce-Domäne in Bounded Contexts abzubilden, Subdomänen zu klassifizieren und Team-Ownership vorzuschlagen.

Erwartetes Ergebnis:

## Subdomain-Klassifizierung

| Fähigkeit | Typ | Begründung | Owner |
|------------|------|------------|-------|
| Produktkatalog | Core | Unterscheidet das Geschäft | Commerce-Team |
| Benutzer-Authentifizierung | Supporting | Erforderlich aber nicht einzigartig | Plattform-Team |
| E-Mail-Zustellung | Generic | utility-Funktion | Plattform-Team |

## Bounded Contexts

| Context | Verantwortung | Upstream | Downstream |
|---------|----------------|----------|------------|
| Katalog | Produktdaten | Lieferanten | Checkout, Suche |
| Checkout | Bestellungen | Katalog | fulfillment |

## Ubiquitous Language

| Begriff | Definition | Context |
|------|-------------|---------|
| Bestellung | Bestätigter Kauf | Checkout |
| SKU | Lagereinheit | Katalog |

Verwendung von "ddd-strategic-design". Nutze @ddd-strategic-design, um uns zu helfen, Subdomänen in unserer Healthcare-Domäne mit Patientenakten, Terminen, Abrechnung und Versicherungsprüfung zu identifizieren.

Erwartetes Ergebnis:

## Subdomain-Klassifizierung

| Fähigkeit | Typ | Begründung | Owner |
|------------|------|------------|-------|
| Patientenakten | Core | Klinische Differenzierung | Clinical-Team |
| Termine | Supporting | Erforderliche Operationen | Operations-Team |
| Abrechnung | Core | Umsatz-Differenzierung | Finance-Team |
| Versicherungsprüfung | Supporting | Ermöglichung | Revenue-Team |

Sicherheitsaudit

Sicher
v1 • 2/24/2026

Static analysis flagged patterns related to backticks and YAML keys. Evaluation confirms all findings are false positives. The skill contains only markdown documentation for DDD methodology. Backticks are markdown formatting for file paths. YAML frontmatter keys like 'source:' and 'risk:' triggered cryptographic pattern detection but are metadata fields. No executable code, network requests, or security concerns detected.

2
Gescannte Dateien
75
Analysierte Zeilen
0
befunde
1
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude

Qualitätsbewertung

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

Was du bauen kannst

Architektur-Design-Sessions

Während Architektur-Workshops einsetzen, um Domänengrenzen abzubilden und Bounded Contexts für eine neue Microservices-Initiative zu definieren.

Monolith-Dekomposition

Anwenden beim Aufteilen eines Monolithen, um Subdomänengrenzen zu identifizieren und zu bestimmen, welche Komponenten in jeden Bounded Context gehören.

Team-Ownership-Mapping

Klare Team-Ownership und Verantwortungsgrenzen durch Bounded Context-Katalogisierung etablieren.

Probiere diese Prompts

Basis-Subdomain-Mapping 
Nutze @ddd-strategic-design, um mir zu helfen, Subdomänen in unserer [domain name]-Domäne zu identifizieren. Wir haben Fähigkeiten für [list key capabilities]. Bitte klassifiziere jede als Core, Supporting oder Generic.
Bounded Context-Definition 
Nutze @ddd-strategic-design, um Bounded Contexts für unsere [domain] zu definieren. Wir haben diese Subdomänen identifiziert: [list subdomains]. Bitte hilf dabei, Bounded Contexts mit klaren Ownership-Grenzen zu erstellen.
Ubiquitous Language-Erstellung 
Nutze @ddd-strategic-design, um ein Ubiquitous Language-Glossar zu erstellen. Für unseren [bounded context] müssen wir diese Begriffe definieren: [list terms]. Inklusive Definitionen und Identifikation widersprüchlicher Bedeutungen.
Vollständiges Strategic Design 
Nutze @ddd-strategic-design, um ein vollständiges Strategic Design für unsere [domain name]-Domäne durchzuführen. Inklusive Subdomain-Klassifizierung, Bounded Context-Katalog mit Abhängigkeiten und Ubiquitous Language-Glossar. Unsere Schlüsselfähigkeiten sind: [list capabilities].

Bewährte Verfahren

  • Domänenexperten in die Subdomain-Klassifizierung einbeziehen, um eine genaue Bewertung des Geschäftswerts sicherzustellen
  • Mit Capability-Mapping beginnen, bevor man in Bounded Contexts eintaucht, für klarere Grenzen
  • Grenzentscheidungen mit expliziter Begründung in ADRs dokumentieren, bevor man mit der Implementierung beginnt

Vermeiden

  • Zu viele Bounded Contexts erstellen, was unnötige Komplexität und Integrations-Overhead einführt
  • Upstream- und Downstream-Abhängigkeiten bei der Definition von Context-Grenzen ignorieren
  • Ubiquitous Language-Erstellung überspringen und annehmen, dass alle dasselbe Vokabular teilen

Häufig gestellte Fragen

Was ist der Unterschied zwischen Subdomains und Bounded Contexts?
Subdomains sind Problem-Space-Konzepte, die Geschäftsfähigkeiten repräsentieren. Bounded Contexts sind Solution-Space-Implementierungen, die ein Domänenmodell encapsulieren. Mehrere Subdomains können einem Bounded Context entsprechen, oder eine Subdomain kann sich über mehrere Contexts erstrecken.
Wann sollte ich diese Skill verwenden versus DDD taktische Patterns?
Verwenden Sie diese Skill für strategische Design-Arbeit: Grenzen definieren, Ownership und Sprache. Verwenden Sie taktische Patterns (Entities, Aggregates, Value Objects) nach Abschluss des Strategic Design, um das Innere jedes Bounded Context zu implementieren.
Wie viele Bounded Contexts sollte ein System haben?
Es gibt keine feste Anzahl. Beginnen Sie mit weniger Contexts und teilen Sie auf, wenn Sie starke Teams finden, die unabhängige Modelle oder unterschiedliche Release-Zyklen benötigen. Zu viele Contexts erzeugen Integrations-Overhead; zu wenige verursachen unnötige Kopplung.
Kann diese Skill bei Microservices-Architektur helfen?
Ja. Strategic Design ist der erste Schritt in der Microservices-Dekomposition. Diese Skill hilft, natürliche Service-Grenzen basierend auf Domänengrenzen zu identifizieren, anstatt technischer Schichtung.
Was ist, wenn Domänenexperten sich über Terminologie nicht einig sind?
Dokumentieren Sie widersprüchliche Definitionen in Ihrem Ubiquitous Language als Anti-Terms. Verwenden Sie Bounded Contexts, um Contexts mit widersprüchlichen Definitionen zu isolieren. Dies ist ein häufiges DDD-Pattern namens Context Mapping.
Funktioniert diese Skill für kleine Projekte?
Bei kleinen Projekten mit stabilen Domänen und einzelnen Teams kann Strategic Design übertrieben sein. Die Skill ist am wertvollsten, wenn Komplexität, mehrere Teams oder Domänenkomplexität die Investition rechtfertigen.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/ddd-strategic-design

Ref

main

Dateistruktur

📁 references/

📄 strategic-design-template.md

📄 SKILL.md