![]()
TEIL I
Eine Architektur aufbauen, die Domänenmodellierung unterstützt
Die meisten Entwickler haben noch nie ein Domänenmodell gesehen, sondern höchstens ein Datenmodell.
– Cyrille Martraire, DDD EU 2017
Die meisten Menschen aus der Entwicklung, mit denen wir über Architektur sprechen, haben irgendwie das Gefühl, dass es besser gehen könnte. Sie versuchen häufig, ein System zu retten, das irgendwo in die falsche Richtung gelaufen ist, und wollen den Ball of Mud wieder mit etwas Struktur versehen. Sie wissen, dass ihre Businesslogik nicht über die ganze Anwendung verteilt sein sollte, aber sie haben keine Idee, wie sie das lösen sollen.
Wir haben festgestellt, dass viele Entwicklerinnen und Entwickler, die gebeten werden, ein neues System zu designen, sofort damit beginnen, ein Datenbankschema aufzubauen, und das Objektmodell erst danach betrachten. Bereits damit fängt das Projekt an, in die falsche Richtung zu laufen, denn stattdessen sollte das Verhalten an erster Stelle stehen und Grundlage für unsere Storage-Anforderungen sein – schließlich kümmern sich unsere Kundinnen und Kunden nicht um das Datenmodell. Ihnen ist nur wichtig, was das System tut – ansonsten würden sie einfach eine Tabellenkalkulation verwenden.
Der erste Teil des Buchs kümmert sich darum, wie man mithilfe von TDD (Test-Driven Development) ein umfassendes Objektmodell aufbaut (in Kapitel 1), anschließend erläutern wir Ihnen, wie Sie dieses Modell von technischen Aspekten getrennt halten können. Wir zeigen Ihnen, wie Sie Code erstellen, der sich nicht um Persistenz kümmert, und wie Sie stabile APIs rund um unsere Domäne schaffen, sodass wir aggressiv refaktorieren können.
Dazu stellen wir vier zentrale Design-Patterns vor:
- Das Repository-Pattern (Kapitel 2) – eine Abstraktion über die Idee von persistentem Storage.
- Das Service-Layer-Pattern (Kapitel 4), mit dem klar definiert wird, wo die Grenzen unserer Use Cases liegen.
- Das Unit-of-Work-Pattern (Kapitel 6), um atomare Operationen zu ermöglichen.
- Das Aggregate-Pattern (Kapitel 7), um die Integrität unserer Daten sicherzustellen.
Würden Sie sich gern ein Bild dessen machen, was da vor uns liegt, schauen Sie sich Abbildung I-1 an. Es sollte Sie aber nicht beunruhigen, wenn Sie davon noch nichts verstehen! Wir stellen in diesem Teil des Buchs Schritt für Schritt jeden Block aus dieser Abbildung vor.
Abbildung I-1: Ein Komponentendiagramm für unsere Anwendung am Ende von Teil I
Wir nehmen uns zudem ein wenig Zeit, um in Kapitel 3 über Kopplung und Abstraktionen zu sprechen, und illustrieren das mit einem einfachen Beispiel, das zeigt, wie und warum wir unsere Abstraktionen gewählt haben.
Drei Anhänge gehen noch tiefer auf einzelne Aspekte der Inhalte von Teil I ein:
- In Anhang B ist die Infrastruktur für unseren Beispielcode zusammengestellt: wie wir die Docker-Images bauen und ausführen, wo wir Konfigurationsinformationen verwalten und wie wir verschiedene Testtypen ausführen.
- In Anhang C finden Sie eine Art »Proof of Concept«, der zeigt, wie einfach es ist, unsere gesamte Infrastruktur auszutauschen – die Flask-API, das ORM und Postgres –, um ein komplett anderes I/O-Modell zu erhalten, das ein CLI und CSVs nutzt.
- Anhang D kann für Sie schließlich interessant sein, wenn Sie sich fragen, wie diese Patterns aussehen würden, wenn statt Flask und SQLAlchemy nun Django zum Einsatz käme.
![]()
KAPITEL 1
Domänenmodellierung
Dieses Kapitel erklärt, wie wir Businessprozesse durch Code so modellieren können, dass dies sehr kompatibel mit TDD ist. Wir werden besprechen, warum Domänenmodellierung wichtig ist, und werden uns ein paar zentrale Patterns dazu anschauen: Entity, Value Object und Domain Service.
In Abbildung 1-1 sehen Sie einen einfachen visuellen Platzhalter für unser Domain-Model-Pattern. In diesem Kapitel bestücken wir es mit Details und bauen in den weiteren Kapiteln auch Dinge darum herum, aber Sie sollten diese Formen immer wiederfinden.
Abbildung 1-1: Eine Platzhalterdarstellung für unser Domänenmodell
Was ist ein Domänenmodell?
In der Einleitung haben wir den Begriff Businesslogikschicht genutzt, um die zentrale Schicht einer Drei-Schichten-Architektur zu beschreiben. Im Rest des Buchs werden wir nun stattdessen den Begriff Domänenmodell verwenden. Dies ist ein Begriff aus der DDD-Community, der unsere beabsichtigte Bedeutung besser umschreibt (in der folgenden Box finden Sie mehr zu DDD).
Die Domäne ist eine schicke Bezeichnung für »das Problem, das Sie lösen wollen«. Beispielsweise arbeiten die...
