Domain Modelling

Domänenmodellierung

Führe eine gemeinsame, schlanke Quelle der Wahrheit für das, was Dinge in diesem Projekt bedeuten, damit Code, Docs, Tickets und Gespräche dieselben Wörter für dieselben Dinge verwenden.

Fokus: $ARGUMENTS (falls leer, modelliere alles, was in dieser Session besprochen wird).

Keine stillschweigenden Annahmen. Der Benutzer besitzt, was Begriffe bedeuten. Eine Definition, ein kanonischer Name, ein Synonym, eine Beziehung, eine Kardinalität oder eine Invariante, die du aus Code, Docs oder Gespräch abgeleitet hast, ist eine Annahme, bis der Benutzer sie bestätigt. Verfolge sie als ✅ bestätigt · ❓ unbestätigt · ❌ abgelehnt und schreibe nur bestätigte als Tatsache in das Domänendokument.

Wo das Modell lebt

• Wenn GLOSSARY.md oder docs/domain.md bereits existiert, verwende es (bevorzuge die vorhandene Datei; erstelle niemals beide).
• Andernfalls erstelle docs/domain.md mit der untenstehenden Struktur.

Prozess

1. Lies das aktuelle Domänendokument und den Code, der die fokussierten Konzepte implementiert (Typen, Schemas, DB-Modelle, API-Verträge). Code ist Beweis für das tatsächliche Modell; das Dokument ist das beabsichtigte — notiere jede Abweichung. Keines von beiden sagt dir, was der Benutzer meint; frage nach jeder Abweichung, anstatt dich für eine Seite zu entscheiden.
2. Extrahiere Kandidatenbegriffe aus dem Gespräch, der Spezifikation oder dem Ticket. Schlage für jeden vor, ob es sich um einen neuen Begriff, einen bestehenden Begriff oder ein Synonym eines bestehenden Begriffs handelt, und lass den Benutzer bestätigen. Zwei Wörter, die ähnlich aussehen, können unterschiedliche Konzepte sein.
3. Löse Unklarheiten mit dem Benutzer. Stelle kurze, konkrete Fragen:
   • "Ist ein Arbeitsbereich dasselbe wie eine Organisation, oder kann eine Organisation mehrere Arbeitsbereiche haben?"
   • "Kann eine Bestellung ohne einen Kunden existieren? Was muss immer für eine Bestellung gelten?" Einige dich mit dem Benutzer auf einen kanonischen Namen pro Konzept (du kannst einen empfehlen); liste abgelehnte Synonyme als Vermeiden auf.
4. Definiere Grenzen: Identität (Entität vs. Value Object), Eigentumsverhältnisse/Aggregate-Wurzeln, Kardinalität, Lebenszyklus/Zustände und Invarianten. Notiere, zu welchem Bounded Context ein Begriff gehört, falls das Projekt mehr als einen hat. Schlage diese aus dem Code vor, falls hilfreich, aber bestätige jeden mit dem Benutzer.
5. Aktualisiere das Dokument nur mit bestätigten Einträgen — minimaler Diff, alphabetisch innerhalb der Abschnitte, keine Aufsätze. Wenn eine Definition ihre Bedeutung ändert, sage dies im Commit/PR, und markiere Code, der den Begriff jetzt falsch verwendet. Wenn der Benutzer mit ungelösten Punkten aufhören möchte, füge sie unter ## Offene Fragen mit ❓ hinzu, niemals ins Glossar.
6. Berichte, was du hinzugefügt/geändert hast, sowie jede Abweichung zwischen Code und Modell (mit datei:zeile) und alle noch offenen ❓ Punkte.

Dokumentstruktur (schlank halten)

# Domänenmodell

## Glossar
| Begriff | Definition | Vermeiden |
|---------|------------|-----------|
| Bestellung | Die bestätigte Anfrage eines Kunden, ein oder mehrere Produkte zu kaufen. | kauf, warenkorb |

## Entitäten & Aggregate
### Bestellung (Aggregate-Wurzel)
- Identität: `OrderId`
- Enthält: Bestellposition (1..n)
- Zustände: entwurf → aufgegeben → bezahlt → versendet | storniert
- Invarianten: gesamt ≥ 0; kann nicht versendet werden, außer bezahlt

## Beziehungen
- Kunde 1 — n Bestellung

## Bounded Contexts (optional)
- Abrechnung: Rechnung, Zahlung

Regeln: Ein Satz pro Definition, wo möglich; definiere Begriffe mit anderen Glossarbegriffen; keine Implementierungsdetails, es sei denn, sie sind die Domäne (z. B. ein ID-Format, das Kunden sehen).