E-Book, Deutsch, 302 Seiten
Reihe: Programmieren mit Python
Test-Driven Development, Domain-Driven Design und Event-Driven Microservices praktisch umgesetzt
E-Book, Deutsch, 302 Seiten
Reihe: Programmieren mit Python
ISBN: 978-3-96010-573-2
Verlag: O'Reilly
Format: EPUB
Kopierschutz: 6 - ePub Watermark
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.
Weitere Infos & Material
Vorwort
Sie fragen sich vielleicht, wer wir sind und warum wir dieses Buch geschrieben haben. Am Ende von Harrys letztem Buch Test-Driven Development with Python (O’Reilly, http://www.obeythetestinggoat.com/) hat er ein paar Fragen rund um Architektur gestellt – zum Beispiel, auf welchem Weg Sie Ihre Anwendung am besten so strukturieren können, dass sie sich leicht testen lässt. Genauer gesagt, geht es darum, wie Ihre zentrale Businesslogik durch Unit Tests abgedeckt werden kann und wie Sie die Menge an erforderlichen Integrations- und End-to-End-Tests minimieren können. Er verwies wolkig auf »hexagonale Architektur«, »Ports und Adapter« sowie »funktionaler Kern, imperative Shell«, aber er musste ehrlich gesagt zugeben, dass er all das nicht so richtig verstanden oder ernsthaft eingesetzt hatte. Aber wie es der Zufall so will, traf er auf Bob, der Antworten auf all diese Fragen hatte. Bob war Softwarearchitekt geworden, weil das kein anderer in seinem Team machen wollte. Es stellte sich heraus, dass er das nicht wirklich gut konnte, aber er wiederum traf glücklicherweise auf Ian Cooper, der ihm neue Wege zeigte, Code zu schreiben und darüber nachzudenken. Komplexität managen, Businessprobleme lösen
Wir arbeiten beide für MADE.com, ein europäisches E-Commerce-Unternehmen, das Möbel über das Internet verkauft. Dort wenden wir die Techniken aus diesem Buch an, um verteilte Systeme aufzubauen, die Businessprobleme aus der Realität modellieren. Unsere Beispieldomäne ist das erste System, das Bob für MADE geschaffen hat, und dieses Buch ist der Versuch, all das aufzuschreiben, was wir neuen Programmiererinnen und Programmierern beibringen müssen, wenn sie in eines unserer Teams kommen. MADE.com agiert mit einer globalen Lieferkette aus Frachtpartnern und Herstellern. Um die Kosten niedrig zu halten, versuchen wir, die Bestände in unseren Lagern so zu optimieren, dass Waren nicht lange herumliegen und Staub ansetzen. Idealerweise wird das Sofa, das Sie kaufen wollen, an genau dem Tag im Hafen eintreffen, an dem Sie sich zum Kauf entscheiden, und wir werden es direkt zu Ihnen liefern, ohne es überhaupt einlagern zu müssen. Dieses Timing richtig hinzubekommen, ist ein überaus kniffliger Balanceakt, wenn die Produkte drei Monate benötigen, bis sie mit dem Containerschiff eintreffen. Auf dem Weg gehen Dinge kaputt, oder es gibt einen Wasserschaden, Stürme können zu unerwarteten Verzögerungen führen, Logistikpartner gehen nicht gut mit den Waren um, Papiere gehen verloren, Kunden ändern ihre Meinung und passen ihre Bestellung an und so weiter. Wir lösen diese Probleme, indem wir intelligente Software bauen, die die Aktionen aus der realen Welt repräsentieren, sodass wir so viel wie möglich automatisieren können. Warum Python?
Wenn Sie dieses Buch lesen, müssen wir Sie wahrscheinlich nicht davon überzeugen, dass Python großartig ist, daher ist die eigentliche Frage: »Warum braucht die Python-Community solch ein Buch?« Die Antwort liegt in der Beliebtheit und dem Alter von Python: Auch wenn sie die vermutlich weltweit am schnellsten wachsende Programmiersprache ist und sich in die Spitze der Tabellen vorarbeitet, kommt sie erst jetzt langsam in den Bereich der Probleme, mit denen sich die C#- und die Java-Welt seit Jahren beschäftigen. Start-ups werden zu ernsthaften Firmen, Webanwendungen und geskriptete Automatisierungshelferlein werden zu (im Flüsterton) Enterprisesoftware. In der Welt von Python zitieren wir häufig das Zen von Python: »Es sollte einen – und möglichst genau einen – offensichtlichen Weg geben, etwas zu tun.«1 Leider ist mit wachsender Projektgröße der offensichtlichste Weg nicht immer der Weg, der Ihnen dabei hilft, die Komplexität und die sich wandelnden Anforderungen im Griff zu behalten. Keine der Techniken und Patterns, die wir in diesem Buch besprechen, ist insgesamt neu, aber sie sind es größtenteils für die Python-Welt. Und dieses Buch ist kein Ersatz für Klassiker wie Eric Evans Domain-Driven Design oder Martin Fowlers Patterns of Enterprise Application Architecture (beide bei Addison-Wesley Professional veröffentlicht) – im Gegenteil, wir beziehen uns oft darauf und raten Ihnen, sie ebenfalls zu lesen. Aber all die klassischen Codebeispiele in der Literatur sind doch meist in Java oder C++/C# geschrieben, und wenn Sie eher eine Python-Person sind und schon lange nicht mehr (oder gar noch nie) eine dieser Sprachen genutzt haben, können diese Codebeispiele doch ziemlich – wie soll man sagen – herausfordernd sein. Es gibt einen Grund dafür, dass die Beispiele in der neuesten Auflage eines weiteren Klassikers – Fowlers Refactoring (Addison-Wesley Professional) – in JavaScript geschrieben sind. TDD, DDD und eventgesteuerte Architektur
In der Reihenfolge ihrer Bekanntheit gibt es drei Werkzeuge, um die Komplexität im Griff zu behalten: Test-Driven Development (TDD) hilft uns dabei, Code zu erstellen, der korrekt ist, und es ermöglicht uns, Features zu refaktorieren oder neu hinzuzufügen, ohne dass wir Angst vor Regressionen haben müssen. Aber es kann sehr schwer sein, das Beste aus unseren Tests herauszuholen: Wie stellen wir sicher, dass sie so schnell wie möglich laufen? Dass wir so viel Abdeckung und Feedback wie möglich aus schnellen, unabhängigen Unit Tests bekommen und so wenig langsamere, anfällige End-to-End-Tests wie möglich einsetzen müssen? Domain-Driven Development (DDD) hilft uns dabei, unsere Arbeit darauf zu konzentrieren, ein gutes Modell der Businessdomäne zu erstellen. Aber wie schaffen wir es, dass unsere Modelle nicht mit Infrastrukturbedenken überladen werden und sich nur schwer ändern lassen? Lose gekoppelte (Micro-)Services, die über Nachrichten miteinander kommunizieren (manchmal als reaktive Microservices bezeichnet), sind eine bewährte Antwort auf den Umgang mit Komplexität über mehrere Anwendungen oder Businessdomänen hinweg. Aber es ist nicht immer offensichtlich, wie Sie sie mit den bekannten Tools der Python-Welt – Flask, Django, Celery und so weiter – aufeinander abstimmen können. Machen Sie sich keine Sorgen, wenn Sie nicht mit Microservices arbeiten (oder auch gar kein Interesse daran haben). Der größte Teil der hier besprochenen Patterns – auch viele aus der eventgesteuerten Architektur – lässt sich ebenfalls wunderbar in einer monolithischen Architektur anwenden. Wir haben uns mit diesem Buch zum Ziel gesetzt, eine Reihe klassischer Architektur-Patterns vorzustellen und zu zeigen, wie sie TDD, DDD und eventgesteuerte Services unterstützen. Wir hoffen, dass es als Referenz für ihre Implementierung auf pythoneske Art und Weise dient und dass die Menschen es als ersten Schritt für weitere Untersuchungen auf diesem Gebiet nutzen können. Wer dieses Buch lesen sollte
Es gibt ein paar Dinge, die wir von unserem Publikum annehmen: Sie hatten bereits mit ein paar halbwegs komplexen Python-Anwendungen zu tun. Sie haben schon die Schmerzen erlebt, die entstehen, wenn man versucht, die Komplexität im Griff zu behalten. Sie müssen nicht unbedingt etwas über DDD oder eines der klassischen Architektur-Patterns wissen. Wir strukturieren unsere Erkundung der Architektur-Patterns rund um eine Beispiel-App, die wir Kapitel für Kapitel aufbauen. In unserem Hauptjob verwenden wir TDD, daher tendieren wir dazu, erst Listings mit Tests zu zeigen, auf die dann Implementierungen folgen. Sind Sie nicht damit vertraut, erst Tests, dann Implementierungen zu schreiben, mag das zu Beginn ein wenig seltsam erscheinen, aber wir hoffen, dass Sie sich schnell daran gewöhnen werden, »verwendeten« Code zu sehen, bevor Sie erfahren, wie er im Inneren aufgebaut ist. Wir nutzen ein paar Python-Frameworks und -Technologien, unter anderem Flask, SQLAlchemy und pytest, dazu Docker und Redis. Sind Sie damit schon vertraut, ist das schön, aber unserer Meinung nach nicht unbedingt erforderlich. Eines unserer Hauptziele bei diesem Buch besteht darin, eine Architektur aufzubauen, für die spezifische Technologieentscheidungen zu unwichtigeren Implementierungsdetails werden. Was lernen Sie in diesem Buch?
Das Buch ist in zwei Teile unterteilt – hier ein Überblick über die Themen, die wir behandeln, und die Kapitel, in denen Sie sie finden werden. Teil I: Eine Architektur aufbauen, die Domänenmodellierung unterstützt Domänenmodellierung und DDD (Kapitel 1 und 7) Wir alle haben mehr oder weniger die Lektion gelernt, dass sich komplexe...
