| Typ | Konzept |
|---|---|
| Quellen | Quelle - Effektive Softwarearchitekturen |
| Erstellt | 2026-09-27 |
| Aktualisiert | 2026-09-27 |
| Tags | softwarearchitektur, ddd, fachdomäne, bounded-context, wam |
Entwurfsmethode nach Eric Evans (2004): Die Fachdomäne steht im Mittelpunkt, Fachleute und Entwickler sprechen eine gemeinsame Sprache. Im Grossen wird die Domäne in abgegrenzte fachliche Kontexte (Bounded Contexts) geschnitten, im Kleinen mit Entities, Value Objects, Aggregaten, Services und Repositories modelliert.
Grundidee
Fachlichkeit und Technik werden getrennt (Entwurfsprinzip). Das Modell der Domäne ist Kern des Systems. Alle Beteiligten verwenden dieselbe Ubiquitous Language (allgegenwärtige Sprache), im Gespräch wie im Code (Quelle - Effektive Softwarearchitekturen, S. 84).
Strategisches Design: im Grossen
- Bounded Context: ein fachlicher Bereich, innerhalb dessen Begriffe eine einheitliche Bedeutung haben. Jeder hat sein eigenes Modell (S. 85).
- Context Map: zeigt, wie die Bounded Contexts zusammenhängen und integriert werden, zum Beispiel mit einem Anticorruption Layer, der ein fremdes Modell übersetzt (aim42).
Beispiel Telefonanbieter (S. 85–87): Bounded Contexts sind Telefonie (Netzbetrieb, Verbindungsdaten), Rechnungswesen, Marketing, Buchhaltung und Kundenbetreuung. „Kunde“ bedeutet überall etwas anderes:
- Im Marketing ist ein Kunde jemand, der künftig Kunde werden könnte. Wichtig sind Budget, Alters- und Interessensgruppe; Verträge gibt es noch keine.
- In der Kundenbetreuung zählen Verträge, Tarife, Kundennummer und SIM-Karten.
- In der Telefonie ist der Kunde nur eine SIM-Karte, über die Gespräche laufen. Die Adresse spielt keine Rolle.
Taktisches Design: im Kleinen
Bausteine innerhalb eines Bounded Context nach Evans (S. 86–88):
| Baustein | Bedeutung |
|---|---|
| Entity | hat eine unveränderliche Identität und einen Lebenszyklus, meist gespeichert |
| Value Object | ohne eigene Identität, beschreibt Eigenschaften, z. B. einen Geldbetrag |
| Domain Event | vergangenes fachliches Ereignis („Kunde wurde angelegt“); aus den Ereignissen lässt sich der Zustand rekonstruieren |
| Service | fachliche Operation ohne eigenen Zustand, die zu keiner Entity passt |
| Aggregate | Gruppe von Objekten mit einer Wurzel-Entity, die nach aussen Konsistenz sichert |
| Factory | erzeugt komplexe Objekte |
| Repository | liefert und speichert Aggregate, verbirgt die Datenbank |
Evans ordnet dies in Schichten: Präsentation, Applikation, Domäne, Infrastruktur (Architekturstil). Viele Praktiker erarbeiten das Wissen über die Domäne mit Event Storming nach Alberto Brandolini, also über fachliche Ereignisse (S. 89).
Werkzeug-Material-Ansatz (WAM)
Ein älterer, europäischer Ansatz von Heinz Züllighoven (Universität Hamburg), im Buch zusammen mit Carola Lilienthal vorgestellt (S. 89–91). Er orientiert sich am Arbeitsplatz:
- Fachwerte sind unveränderliche Werte wie Betrag oder Kontonummer.
- Materialien sind die Gegenstände der Arbeit, etwa ein Vertrag oder ein Konto.
- Fachliche Services bündeln fachliches Wissen zustandslos (BuchungsService).
- Werkzeuge dienen dem Menschen, um Materialien zu bearbeiten (Vertragseditor).
- Automaten erledigen Routinetätigkeiten ohne Interaktion.
- Technische Services stellen technische Dienste bereit.
Starke hält WAM für „völlig unberechtigt“ in einem Nischendasein (S. 91).
Bounded Contexts sind eine häufige Grundlage, um Microservices zu schneiden: ein Kontext, ein Dienst, ein Team (Conway's Law). Die Idee, dass derselbe Begriff je nach Abteilung Verschiedenes bedeutet, kennt auch die BWL: Ein „Kunde“ ist für das Marketing ein Segment, für die Buchhaltung ein Debitor (Marktforschung). Beides ist nicht aus dem Buch belegt.
Verwandt
- Entwurfsprinzip – Fachlichkeit und Technik trennen
- Architekturstil – Schichten, Ports und Adapter, Event Sourcing
- Microservices – Schnitt entlang der Bounded Contexts
- aim42 – Anticorruption Layer, „extract business domain“
- Informationsarchitektur – Begriffe der Nutzer ordnen, aus UX-Sicht