---
name: domain-modellieren
description: Schärft Fachsprache, Regeln, Beispiele, Bounded Contexts und bei Bedarf ein tragfähiges Domain-Modell. Verwenden, wenn Begriffe mehrdeutig sind, Fachbereich und Entwicklung ein gemeinsames Modell benötigen, Geschäftsregeln geklärt oder Vertical Slices fachlich eingeordnet werden sollen.
---

# Domäne modellieren

Entwickle das Modell gemeinsam mit dem Fachbereich anhand konkreter Beispiele.
Halte nur bestätigtes Wissen fest und lasse offene Fragen sichtbar.

## Fachliche Grundlage

- [Eric Evans – DDD Reference](https://www.domainlanguage.com/ddd/reference/)
  fasst die Begriffe und Muster aus *Domain-Driven Design* zusammen.
- [Martin Fowler – Ubiquitous Language](https://martinfowler.com/bliki/UbiquitousLanguage.html)
  beschreibt die gemeinsame, im Gespräch und in Software verwendete
  Fachsprache.
- [Martin Fowler – Bounded Context](https://martinfowler.com/bliki/BoundedContext.html)
  beschreibt getrennte, intern konsistente Modelle und ihre Beziehungen.

## Artefakt

Verwende `docs/domain/DOMAIN.md`. Lege es aus
`docs/templates/domain-template.md` erst an, wenn der erste Begriff, die erste
Regel oder eine Kontextgrenze tatsächlich geklärt wurde. Es ist ein lebendes
fachliches Modell, kein Sitzungsprotokoll und keine Kopie des Codes.

## Vorgehen

1. Lies `PROJECT.md`, vorhandenes Domänenwissen, relevante ADRs, Code und Tests.
2. Beginne mit einem realen fachlichen Beispiel oder einer Nutzeraufgabe.
   Stelle höchstens eine Frage auf einmal.
3. Kläre mehrdeutige Begriffe sofort. Frage etwa, ob „Kunde“, „Benutzer“ und
   „Vertragspartner“ wirklich dasselbe bedeuten.
4. Prüfe Regeln mit Normal-, Grenz- und Gegenbeispielen. Erfinde keine Regel,
   nur um das Modell vollständig wirken zu lassen.
5. Halte bestätigte Begriffe, Regeln und Beispiele unmittelbar in
   `docs/domain/DOMAIN.md` fest. Markiere Unbestätigtes als Entwurf oder offene
   Frage.
6. Trenne Bounded Contexts erst, wenn Sprache, Verantwortung oder Modell
   erkennbar wechseln. Verwende bei mehreren Kontexten eine kleine Context Map.
7. Ordne Vertical Slices einem Bounded Context und einem fachlichen Ziel zu.
   Ein Slice darf einfach bleiben; ziehe gemeinsame Fachregeln erst bei realer
   Komplexität in ein Domain-Modell.
8. Verwende Entities, Value Objects, Aggregate, Domain Services oder Domain
   Events nur, wenn damit eine konkrete Regel oder Konsistenzgrenze klarer wird.
9. Kläre mit `sicherheit-und-datenschutz-pruefen`, welche Begriffe Daten über
   Personen, Berechtigungen, Eigentum, Einwilligung oder Aufbewahrung tragen.
10. Überführe bestätigte Beispiele mit `testgetrieben-entwickeln` in Tests.
   Nutze `system-visualisieren`, wenn Beziehungen oder Zustände im Text schwer
   verständlich werden.
11. Sprich Widersprüche zwischen Fachsprache, Dokument, Code und Tests an,
    statt eine Quelle stillschweigend zu bevorzugen.

## Schlank bleiben

- Kein vollständiges Unternehmensmodell im Voraus erstellen.
- Nicht jedes Substantiv zu einer Entity und nicht jede Tabelle zu einem
  Aggregate erklären.
- Einfache CRUD- oder Lesefunktionen nicht mit taktischen DDD-Mustern belasten.
- Implementierungsdetails nur aufnehmen, wenn sie fachliche Bedeutung haben.
- Ein ADR nur über `entscheidung-festhalten` anlegen, wenn eine dauerhafte
  Entscheidung vorliegt.

## Fertig, wenn

- Fachbereich und Entwicklung dieselben Begriffe gleich verwenden.
- Regeln durch konkrete Beispiele und Gegenbeispiele verständlich sind.
- Kontextgrenzen nur dort bestehen, wo unterschiedliche Modelle nötig sind.
- offene Fragen und der Bestätigungsstatus sichtbar bleiben.
- Code und Tests die bestätigte Fachsprache verwenden oder Abweichungen
  ausdrücklich begründen.