Architekturpatterns mit Python
Test-Driven Development, Domain-Driven Design und Event-Driven Microservices praktisch umgesetzt
1st Edition
Published on 4. September 2021
302 pages
978-3-96010-572-5 (ISBN)
Available for download
Description
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.
More details
Other editions
Additional editions
Harry J. W. Percival | Bob Gregory | Thomas Demmig
Architekturpatterns mit Python
Test-Driven Development, Domain-Driven Design und Event-Driven Microservices praktisch umgesetzt
Book
09/2021
O'Reilly
€41.90
Article exhausted; check different version
Harry J. W. Percival | Bob Gregory
Architekturpatterns mit Python
Test-Driven Development, Domain-Driven Design und Event-Driven Microservices praktisch umgesetzt
Book
09/2021
1st Edition
O'Reilly
€36.90
Available immediately
Persons
Anna Dahlström ist eine schwedische UX-Designerin mit Sitz in London und die Gründerin von UX Fika. Seit 2001 arbeitet sie für Kund*innen, Agenturen und Start-ups an einer Vielzahl von Marken und Projekten, von Websites und Apps bis hin zu Bots und TV-Interfaces.
Content
- Cover
- Titel
- Impressum
- Inhalt
- Vorwort
- Einleitung
- Teil I Eine Architektur aufbauen, die Domänenmodellierung unterstützt
- 1 Domänenmodellierung
- Was ist ein Domänenmodell?
- Die Domänensprache untersuchen
- Unit Testing für Domänenmodelle
- Dataclasses sind großartig für Value Objects
- Value Objects und Entitäten
- Nicht alles muss ein Objekt sein: eine Domänenservice-Funktion
- Pythons magische Methoden lassen uns unsere Modelle mit idiomatischem Python nutzen
- Auch Exceptions können Domänenkonzepte ausdrücken
- 2 Repository-Pattern
- Unser Domänenmodell persistieren
- Etwas Pseudocode: Was werden wir brauchen?
- DIP auf den Datenzugriff anwenden
- Erinnerung: unser Modell
- Der »normale« ORM-Weg: Das Modell hängt vom ORM ab
- Die Abhängigkeit umkehren: ORM hängt vom Modell ab
- Das Repository-Pattern
- Das Repository im Abstrakten
- Vor- und Nachteile
- Es ist nicht einfach, ein Fake-Repository für Tests zu erstellen!
- Was ist in Python ein Port und was ein Adapter?
- Zusammenfassung
- 3 Ein kleiner Exkurs zu Kopplung und Abstraktionen
- Das Abstrahieren eines Status verbessert die Testbarkeit
- Die richtige(n) Abstraktion(en) wählen
- Unsere gewählten Abstraktionen implementieren
- Edge-to-Edge-Tests mit Fakes und Dependency Injection
- Warum nicht einfach herauspatchen?
- Zusammenfassung
- 4 Unser erster Use Case: Flask-API und Serviceschicht
- Unsere Anwendung mit der echten Welt verbinden
- Ein erster End-to-End-Test
- Die direkte Implementierung
- Fehlerbedingungen, die Datenbank-Checks erfordern
- Einführen eines Service Layer und Einsatz von FakeRepository für die Unit Tests
- Eine typische Servicefunktion
- Warum wird alles als Service bezeichnet?
- Dinge in Ordnern ablegen, um zu sehen, wohin sie gehören
- Zusammenfassung
- Das DIP in Aktion
- 5 TDD hoch- und niedertourig
- Wie sieht unsere Testpyramide aus?
- Sollten Tests der Domänenschicht in den Service Layer verschoben werden?
- Entscheiden, was für Tests wir schreiben
- Hoch- und niedertourig
- Tests für den Service Layer vollständig von der Domäne entkoppeln
- Linderung: alle Domänenabhängigkeiten in Fixture-Funktionen unterbringen
- Einen fehlenden Service hinzufügen
- Die Verbesserung in die E2E-Tests bringen
- Zusammenfassung
- 6 Unit-of-Work-Pattern
- Die Unit of Work arbeitet mit dem Repository zusammen
- Eine UoW über Integrationstests voranbringen
- Unit of Work und ihr Context Manager
- Die echte Unit of Work nutzt SQLAlchemy-Sessions
- Fake Unit of Work zum Testen
- Die UoW im Service Layer einsetzen
- Explizite Tests für das Commit/Rollback-Verhalten
- Explizite versus implizite Commits
- Beispiele: mit UoW mehrere Operationen in einer atomaren Einheit gruppieren
- Beispiel 1: Neuzuteilung von Aufträgen
- Beispiel 2: Chargengröße ändern
- Die Integrationstests aufräumen
- Zusammenfassung
- 7 Aggregate und Konsistenzgrenzen
- Warum nehmen wir nicht einfach eine Tabellenkalkulation?
- Invarianten, Constraints und Konsistenz
- Invarianten, Concurrency und Sperren
- Was ist ein Aggregat?
- Ein Aggregat wählen
- Ein Aggregat = ein Repository
- Und was ist mit der Performance?
- Optimistische Concurrency mit Versionsnummern
- Optionen für Versionsnummern implementieren
- Unsere Regeln zur Datenintegrität testen
- Concurrency-Regeln durch den Einsatz von Isolation Level für Datenbanktransaktionen sicherstellen
- Beispiel zur pessimistischen Concurrency-Steuerung: SELECT FOR UPDATE
- Zusammenfassung
- Teil I - Zusammenfassung
- Teil II Eventgesteuerte Architektur
- 8 Events und der Message Bus
- Vermeiden Sie ein Chaos
- Zuerst einmal vermeiden wir ein Chaos in unseren Webcontrollern
- Unser Modell soll auch nicht chaotisch werden
- Vielleicht im Service Layer?
- Single Responsibility Principle
- Alles einsteigen in den Message Bus!
- Das Modell zeichnet Events auf
- Events sind einfache Dataclasses
- Das Modell wirft Events
- Der Message Bus bildet Events auf Handler ab
- Option 1: Der Service Layer übernimmt Events aus dem Modell und gibt sie an den Message Bus weiter
- Option 2: Der Service Layer wirft seine eigenen Events
- Option 3: Die UoW gibt Events an den Message Bus
- Zusammenfassung
- 9 Ab ins Getümmel mit dem Message Bus
- Eine neue Anforderung bringt uns zu einer neuen Architektur
- Stellen wir uns eine Architekturänderung vor: Alles wird ein Event-Handler sein
- Servicefunktionen in Message-Handler refaktorieren
- Der Message Bus sammelt jetzt Events von der UoW ein
- Die Tests sind ebenfalls alle anhand von Events geschrieben
- Ein vorübergehender hässlicher Hack: Der Message Bus muss Ergebnisse zurückgeben
- Unsere API für die Arbeit mit Events anpassen
- Unsere neue Anforderung implementieren
- Unser neues Event
- Test-Drive für einen neuen Handler
- Implementierung
- Eine neue Methode im Domänenmodell
- Optional: isolierte Unit Tests für Event-Handler mit einem Fake-Message-Bus
- Zusammenfassung
- Was haben wir erreicht?
- Warum haben wir das erreicht?
- 10 Befehle und Befehls-Handler
- Befehle und Events
- Unterschiede beim Exception Handling
- Events, Befehle und Fehlerbehandlung
- Synchrones Wiederherstellen aus Fehlersituationen
- Zusammenfassung
- 11 Eventgesteuerte Architektur: Events zum Integrieren von Microservices
- Distributed Ball of Mud und Denken in Nomen
- Fehlerbehandlung in verteilten Systemen
- Die Alternative: temporales Entkoppeln durch asynchrone Nachrichten
- Einen Redis Pub/Sub Channel zur Integration verwenden
- Mit einem End-to-End-Test alles überprüfen
- Redis ist ein weiterer schlanker Adapter für unseren Message Bus
- Unser neues Event in die Außenwelt
- Interne und externe Events
- Zusammenfassung
- 12 Command-Query Responsibility Segregation (CQRS)
- Domänenmodelle sind zum Schreiben da
- Die meisten Kundinnen und Kunden werden Ihre Möbel nicht kaufen
- Post/Redirect/Get und CQS
- Ruhe bewahren!
- CQRS-Views testen
- »Offensichtliche« Alternative 1: Das bestehende Repository verwenden
- Ihr Domänenmodell ist nicht für Leseoperationen optimiert
- »Offensichtliche« Alternative 2: Verwenden des ORM
- SELECT N+1 und andere Performanceüberlegungen
- Ziehen wir die Reißleine
- Eine Tabelle im Lesemodell mit einem Event-Handler aktualisieren
- Es ist einfach, die Implementierung unseres Lesemodells zu verändern
- Zusammenfassung
- 13 Dependency Injection (und Bootstrapping)
- Implizite und explizite Abhängigkeiten
- Sind explizite Abhängigkeiten nicht total schräg und javaesk?
- Handler vorbereiten: manuelles DI mit Closures und Partials
- Eine Alternative mit Klassen
- Ein Bootstrap-Skript
- Der Message Bus bekommt die Handler zur Laufzeit
- Bootstrap in unseren Einstiegspunkten verwenden
- DI in unseren Tests initialisieren
- Einen Adapter »sauber« bauen: ein größeres Beispiel
- Abstrakte und konkrete Implementierungen definieren
- Eine Fake-Version für die Tests erstellen
- Wie führen wir einen Integrationstest durch?
- Zusammenfassung
- 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
