Architekturpatterns mit Python

Test-Driven Development, Domain-Driven Design und Event-Driven Microservices praktisch umgesetzt

Harry J. W. Percival, Bob Gregory, Thomas Demmig

• Verlag: O'Reilly
• Jahr: 2021
• ISBN:
  9783960105732
• Auflage: 1
• Thema: Computer Science
• Thema: Software Development

Bewährte Patterns für komplexe Python-Projekte

• bekannte Architekturpatterns - endlich in idiomatischem Python
• die Komplexität anspruchsvoller Projekte erfolgreich managen
• den größten Nutzen aus den Testsuiten herausholen

Pythons Popularität wächst weiterhin und mit Python werden inzwischen komplexe Projekte realisiert. Viele Python-Entwicklerinnen und -Entwickler interessieren sich deshalb für High-Level-Design-Patterns wie hexagonale Architektur, ereignisgesteuerte Architektur und die strategischen Patterns, die durch das Domain-Driven Design vorgegeben sind. Das Übertragen dieser Patterns nach Python ist allerdings nicht immer einfach.
In diesem Praxisbuch stellen Harry Percival und Bob Gregory von MADE.com erprobte Architekturpatterns vor, die Python-Entwickler dabei unterstützen, die Komplexität von Anwendungen im Griff zu behalten – und den größtmöglichen Nutzen aus den Testsuiten zu ziehen. Jedes Pattern wird durch Beispiele in schönem, idiomatischem Python illustriert; dabei wird die Weitschweifigkeit der Java- oder C#-Syntax vermieden.

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...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Inhalt
• Vorwort
• Einleitung
• Teil I Eine Architektur aufbauen, die Domänenmodellierung unterstützt
• Teil II Eventgesteuerte Architektur
• Epilog
• Anhang A Übersichtsdiagramm und -tabelle
• Anhang B Eine Template-Projektstruktur
• Anhang C Austauschen der Infrastruktur: alles mit CSVs
• Anhang D Repository- und Unit-of-Work-Pattern mit Django
• Anhang E Validierung
• Fußnoten
• Index
• Über die Autoren
• Kolophon