domain-modeling
Präzise Domain-Modelle mit aktivem Vokabular erstellen
Softwareprojekte leiden, wenn Teams uneinheitliche Terminologie verwenden oder den Überblick verlieren, warum Entscheidungen getroffen wurden. Dieser Skill hilft Ihnen, Ihr Domain-Modell aktiv aufzubauen und zu schärfen, indem Begriffe hinterfragt, Grenzfälle erfunden und Entscheidungen in CONTEXT.md und ADRs festgehalten werden.
Die Skill-ZIP herunterladen
In Claude hochladen
Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen
Einschalten und loslegen
Teste es
Verwendung von "domain-modeling". Benutzer sagt: 'Wenn ein Kunde seine Bestellung storniert, müssen wir die Zahlung erstatten.'
Erwartetes Ergebnis:
Antwort: "Dein Glossar definiert 'Stornierung' als Beendigung einer Bestellung vor der Erfüllung, aber Erstattung ist ein Abrechnungskonzept. Stornierst du die Bestellung und löst ein Erstattungsereignis im Billing aus, oder ist die Stornierung selbst eine Billing-Operation? Lass uns festhalten, welcher Kontext dafür verantwortlich ist."
Verwendung von "domain-modeling". Benutzer entscheidet sich, PostgreSQL für das Write-Model in einem Event-Sourcing-System zu verwenden.
Erwartetes Ergebnis:
Antwort: "Dies qualifiziert sich für ein ADR — schwer umkehrbar (Datenbankwahl), überraschend ohne Kontext (warum Postgres statt eines Event-Stores?), echter Trade-off (Alternativen wurden geprüft). Erstelle jetzt ADR-0003-postgres-fuer-write-model.md."
Sicherheitsaudit
SicherThis skill contains only markdown documentation describing domain modeling practices, CONTEXT.md format, and ADR format. Static analysis flagged false positives: backtick matches are markdown inline code formatting, not shell execution; cryptographic matches are coincidental word fragments in documentation; system reconnaissance flags refer to file path references in examples, not actual filesystem access. No executable code, scripts, network calls, or malicious patterns were found.
Risikofaktoren
📁 Dateisystemzugriff (3)
Qualitätsbewertung
Was du bauen kannst
Ein neues Domain-Modell starten
Verwenden Sie dies zu Beginn eines neuen Projekts, um das anfängliche Vokabular festzulegen und wichtige architektonische Entscheidungen zu dokumentieren, bevor Code geschrieben wird.
Terminologiekonflikte auflösen
Verwenden Sie dies in Teamdiskussionen, wenn verschiedene Teammitglieder unterschiedliche Wörter für dasselbe Konzept verwenden und Klarheit erforderlich ist.
Architekturentscheidungen dokumentieren
Verwenden Sie dies bei wichtigen Technologieentscheidungen, die zukünftige Entwickler verstehen müssen, wie z. B. Datenbankauswahl oder Integrationsmuster.
Probiere diese Prompts
Hilf mir, das Domain-Modell für dieses Projekt aufzubauen. Lies zunächst CONTEXT.md (falls vorhanden) und hinterfrage dann aktiv jede Terminologie, die ich in unserer Diskussion verwende.
Ich habe gerade den Begriff "Account" in unserer Diskussion verwendet. Prüfe CONTEXT.md und sage mir, ob dies mit unserem definierten Vokabular kollidiert, und schlage dann den präzisen Begriff vor, den wir verwenden sollten.
Wir haben gerade die Beziehung zwischen Order und Invoice definiert. Erfinde 3 Grenzfallszenarien, die die Grenze zwischen diesen beiden Konzepten ausloten und uns zwingen, präzise zu sein.
Wir haben uns gerade entschieden, Event Sourcing für das Write-Model zu verwenden. Prüfe, ob dies alle drei ADR-Kriterien erfüllt (schwer umkehrbar, überraschend ohne Kontext, echter Trade-off). Wenn ja, erstelle das ADR mit dem Format aus ADR-FORMAT.md.
Bewährte Verfahren
- Erstelle CONTEXT.md und ADRs lazy — nur wenn du etwas Sinnvolles festzuhalten hast
- Hinterfrage jeden mehrdeutigen Begriff sofort, anstatt Verwirrung anwachsen zu lassen
- Halte CONTEXT.md-Definitionen auf ein bis zwei Sätze, die sich darauf konzentrieren, WAS der Begriff IST
- Schreibe ADRs nur für Entscheidungen, die schwer umkehrbar sind, ohne Kontext überraschen oder echte Trade-offs beinhalten
Vermeiden
- CONTEXT.md als Spec oder Notizbuch für Implementierungsdetails behandeln
- ADRs für offensichtliche Entscheidungen schreiben, die keine echten Alternativen haben
- Allgemeine Programmierkonzepte (Timeouts, Fehlertypen) zum Glossar hinzufügen
- Terminologie-Updates sammeln und auf einmal erledigen, anstatt sie inline festzuhalten, sobald sie geklärt sind