💪🏾 🗑️ 💠 Domain Driven Design Tools ⛪️ 👩🏼‍🤝‍👨🏾 🍅

Der Blauwal ist ein großartiges Beispiel dafür, wie das Design eines komplexen Projekts schief gelaufen ist. Der Wal sieht aus wie ein Fisch, ist aber ein Säugetier: Er füttert die Jungen mit Milch, er hat Wolle, und die Knochen des Unterarms und der Hände mit den Fingern sind wie an Land in den Flossen erhalten. Er lebt in den Ozeanen, kann aber unter Wasser nicht atmen und steigt regelmäßig an die Oberfläche, um Luft zu schlucken, auch wenn er schläft. Der Wal ist das größte Tier der Welt, hat die Länge eines neunstöckigen Hauses und wiegt 75 Volkswagen Touareg-Autos, ist aber kein Raubtier, sondern ernährt sich von Plankton.

Als die Entwickler am Wal arbeiteten, fingen sie nicht an, alles von Grund auf neu zu schreiben, sondern nutzten die Erfahrungen aus alten Projekten. Es scheint aus inkompatiblen Teilen des Codes zusammengeschustert zu sein, die nicht getestet wurden, und das gesamte Design bestand darin, ein Framework zu wählen und dringend bereits in der Produktion zu „radeln“. Infolgedessen erwies sich das Projekt als wunderschön, aber mit dichtem Erbe und Krücken unter der Haube.

Um Projekte zu entwickeln, mit denen Unternehmen Geld verdienen können, anstatt wie ein Meerestier auszusehen, das unter Wasser nicht atmen kann, gibt es DDD. Dies ist ein Ansatz, der sich nicht auf Tools oder Code konzentriert, sondern auf das Studium des Themenbereichs, einzelner Geschäftsprozesse und der Funktionsweise von Code oder Tools für die Geschäftslogik.

Was ist DDD und welche Tools sind darin enthalten? Wir werden in einem Artikel basierend auf dem Bericht erzählenArtyom Malyshev . Der DDD-Ansatz in Python, Tools, Fallstricke, Vertragsprogrammierung und Produktdesign rund um das zu lösende Problem und nicht das verwendete Framework sind unter dem Strich.

Vollständige Präsentation des Berichts .

Artem Malyshev (Proofit404) - Ein unabhängiger Entwickler, der 5 Jahre in Python geschrieben hat, hat aktiv mit Django Channels 1.0 geholfen. Später konzentrierte er sich auf architektonische Ansätze: Er untersuchte, welche Werkzeuge Python-Architekten fehlen, und startete ein Dry-Python- Projekt . Mitbegründer von Drylabs.

Komplexität

Was ist Programmierung?

Das Programmieren ist ein ständiger Kampf mit der Komplexität, die Entwickler selbst erzeugen, wenn sie versuchen, Probleme zu lösen.

Die Komplexität wird in zwei Typen unterteilt: eingeführt und natürlich. Die vorgestellte Version erweitert sich um Programmiersprachen, Frameworks, Betriebssysteme und Asynchronitätsmodelle. Dies ist eine technische Herausforderung , die nicht für Unternehmen gilt. Natürliche Komplexität ist im Produkt verborgen und vereinfacht das Leben der Benutzer - dafür zahlen die Menschen Geld.

Gute Ingenieure sollten die zusätzliche Komplexität reduzieren und die natürliche erhöhen, um den Nutzen des Produkts zu erhöhen.

Aber wir Programmierer sind komplexe Leute und wir lieben es, Projekten technische Komplexität zu verleihen. Zum Beispiel haben wir uns nicht mit Codierungsstandards beschäftigt, keine linternen, modularen Entwurfspraktiken verwendet und in Projekten viel Stilcode erhalten if c==1.

Wie arbeite ich mit solchem Code? Lesen Sie viele Dateien, verstehen Sie Variablen, Bedingungen und wann und wie alles funktionieren wird. Dieser Code ist schwer zu merken - absolut technisch zusätzliche Komplexität.

Ein weiteres Beispiel für zusätzliche Komplexität ist meine Lieblings-Rückruf-Hölle.

Wenn wir im Rahmen einer ereignisorientierten Architektur (EDA) schreiben und ein nicht so gutes modernes Rahmenwerk wählen, erhalten wir einen Code, in dem nicht klar ist, was wann passiert. Es ist schwer, einen solchen Code zu lesen - dies ist wiederum die zusätzliche Komplexität.

Programmierer lieben nicht nur technische Schwierigkeiten, sondern argumentieren auch, welche besser ist:

AsyncIO oder Gevent;
PostgreSQL oder MongoDB;
Python oder Go;
Emacs oder Vim;
Tabulatoren oder Leerzeichen;

Die richtige Antwort eines guten Programmierers auf all diese Fragen: "Es macht keinen Unterschied!" Gute Entwickler streiten sich nicht im luftleeren Raum über kugelförmige Pferde, sondern lösen geschäftliche Probleme und arbeiten an der Nützlichkeit des Produkts. Einige von ihnen haben seit langem eine Reihe von Praktiken etabliert, die die eingeführte Komplexität reduzieren und Ihnen helfen, mehr über das Geschäft nachzudenken.

Einer von ihnen ist Eric Evans . 2004 schrieb er das Buch Domain Driven Design. Sie „schoss“ und gab den Impuls, mehr über das Geschäft nachzudenken und die technischen Details in den Hintergrund zu rücken.

Was ist DDD?

Zuerst eine Lösung für das Problem und dann Werkzeuge . Zunächst investierte Evans in das Konzept von DDD, dass dies keine Technologie, sondern eine Philosophie ist. In der Philosophie müssen Sie zuerst darüber nachdenken, wie Sie das Problem lösen können, und erst dann mit Hilfe der Tools.

Arbeiten Sie mit Fachexperten und Softwareentwicklern an Modellen. Wir müssen mit Menschen aus der Wirtschaft kommunizieren: Suchen Sie nach einer gemeinsamen Sprache, bauen Sie ein Modell der Welt auf, in der unser Produkt funktioniert, und lösen Sie Probleme.

Schreiben Sie Software, die Modelle explizit ausdrückt. Der wichtigste Unterschied zwischen DDD und einfacher Zusammenarbeit in einem Team besteht darin, dass wir Software im gleichen Stil schreiben sollten, wie wir mit Domain-Experten sprechen. Alle Begriffe, Ansätze zur Diskussion und Entscheidungsfindung sollten im Quellcode gespeichert werden, damit auch eine nicht technische Person verstehen kann, was dort passiert.

Sprechen Sie die gleiche Sprache mit dem Geschäft . DDD ist eine Philosophie, wie man mit Geschäftsexperten in einem bestimmten Bereich dieselbe Sprache spricht und Terminologie auf diesen Bereich anwendet. Wir haben eine gemeinsame Sprache oder einen gemeinsamen Dialekt innerhalb des gebundenen Kontexts, den wir für wahr halten. Wir schaffen Grenzen um architektonische Lösungen.

Bei DDD geht es nicht um Technologie.

Zuerst der technische Teil, dann - DDD. Der Bildhauer, der die Statue aus Stein schnitzt, liest das Handbuch zum Halten von Hammer und Meißel nicht - er weiß bereits, wie man mit ihnen arbeitet. Um DDD in Ihr Projekt zu bringen, beherrschen Sie den technischen Teil: Lernen Sie Django bis zum Ende, lesen Sie das Tutorial und hören Sie auf zu streiten, ob Sie PostgreSQL oder MongoDB verwenden möchten.

Die meisten Entwurfsmuster und -muster sind technisches Rauschen. Die meisten Muster, die wir kennen und verwenden, sind technisch. Sie sagen, wie man Code wiederverwendet, wie man ihn strukturiert, aber sie sagen nicht, wie man ihn für Benutzer, Unternehmen und das Modellieren der Außenwelt verwendet. Daher sind Fabriken oder abstrakte Klassen lose an DDD gebunden.

Das erste „blaue“ Buch erschien vor fast 20 Jahren. Die Leute versuchten, in diesem Stil zu schreiben, gingen einen Rechen und stellten fest, dass die Philosophie gut, aber in der Praxis unverständlich ist. Daher erschien ein zweites Buch - "rot" - darüber, wie Programmierer in DDD denken und schreiben.

Die "roten" und "blauen" Bücher sind die Säulen, auf denen alle DDD stehen.

Hinweis. Die roten und blauen Bücher sind eine einzigartige Informationsquelle über DDD, aber sie sind schwer. Bücher sind nicht leicht zu lesen: im Original wegen der komplexen Sprache und Begriffe und auf Russisch wegen der schlechten Übersetzung. Beginnen Sie daher mit einem grünen Buch , DDD zu lernen . Dies ist eine vereinfachte Version der ersten beiden mit einfacheren Beispielen und allgemeinen Beschreibungen. Aber es ist besser, als wenn die roten und blauen Bücher Ihren Wunsch, DDD zu studieren und anzuwenden, zunichte machen. Es ist besser, das Original einzulesen.

Das rote Buch überspringt die Idee, wie DDD am besten in das Projekt einbezogen werden kann und wie die Arbeit um diesen Ansatz herum strukturiert werden kann. Es erscheint eine neue Terminologie - „Model-Driven Design“, bei der unser Modell der Außenwelt an erster Stelle steht.

Die einzige Ortstechnologie, die ausgewählt wird, ist Smart UI. Dies ist eine Schicht zwischen der Außenwelt, dem Benutzer und uns (ein Hinweis auf Robert Martin und seine saubere Architektur mit Schichten). Wie Sie sehen können, geht alles zum Modell.

Was ist ein Modell? Dies ist der Phantomschmerz eines jeden Architekten. Jeder denkt, das ist UML, aber das ist es nicht.

Ein Modell besteht aus einer Reihe von Klassen, Methoden und Verknüpfungen zwischen ihnen, die die Geschäftsszenarien im Programm widerspiegeln.

Das Modell spiegelt ein reales Objekt mit allen notwendigen Eigenschaften und Funktionen wider. Dies ist ein Toolkit auf hoher Ebene, mit dem Entscheidungen aus Sicht von Geschäftsfällen getroffen werden können. Methoden und Klassen sind jedoch ein einfaches Toolkit für Architekturlösungen.

Trockene Python

Um die Modellnische zu füllen, habe ich ein Dry-Python- Projekt gestartet , das sich zu einer Sammlung hochrangiger Architekturbibliotheken für das Erstellen von Model Driven Design entwickelt hat. Jede der Bibliotheken versucht, einen Kreis in der Architektur zu schließen und stört den anderen nicht. Bibliotheken können einzeln oder zusammen verwendet werden, wenn Sie einen Geschmack bekommen.

Die Reihenfolge der Erzählung entspricht der Chronologie der optimalen Hinzufügung von DDD zum Projekt - nach Schichten. Die erste Schicht sind Services , eine Beschreibung der Geschäftsszenarien (Prozesse) in unserem System. Die Stories-Bibliothek ist für diese Ebene verantwortlich.

Geschichten

Geschäftsszenarien sind in drei Teile unterteilt:

Spezifikation - eine Beschreibung des Geschäftsprozesses;
Der Zustand, in dem das Geschäftsszenario existieren kann
Implementierung jedes Schritts des Skripts.

Diese Teile dürfen nicht gemischt werden. Die Stories-Bibliothek trennt diese Teile und zeichnet eine klare Linie zwischen ihnen.

Betrachten Sie die Einführung von DDD und Stories anhand eines Beispiels. Zum Beispiel haben wir ein Projekt über Django mit einer Mischung aus Django-Signalen und obskuren „dicken“ Modellen. Fügen Sie ein leeres Servicepaket hinzu. Mit der Stories-Bibliothek in Teilen schreiben wir diesen Hash in einen klaren und verständlichen Satz von Skripten in unserem Projekt um.

DSL-Spezifikation. In der Bibliothek können Sie eine Spezifikation schreiben und hierfür DSL bereitstellen. Auf diese Weise können Benutzeraktionen Schritt für Schritt beschrieben werden. Zum Kaufen subscriptionfolge ich zum Beispiel mehreren Schritten: Ich finde eine Bestellung, überprüfe die Relevanz des Preises und prüfe, ob der Benutzer es sich leisten kann. Dies ist eine allgemeine Beschreibung.

Vertrag.Unterhalb dieser Klasse schreiben wir einen Vertrag über den Stand des Geschäftsszenarios. Zu diesem Zweck bezeichnen wir den Bereich der Variablen, die im Geschäftsprozess auftreten, und weisen jeder Variablen eine Reihe von Validatoren zu.

Sobald jemand versucht, diesem Bereich im Rahmen des Geschäftsprozesses eine Variable zuzuweisen, wird eine Reihe von Validatoren ausgearbeitet. Wir werden sicher sein, dass der Status des Prozesses zur Laufzeit immer funktioniert. Aber wenn nicht, fällt es schmerzhaft und schreit laut darüber.

Umsetzungsphase jedes Schritts . In derselben Klasse subscriptionschreiben wir eine Reihe von Methoden, deren Namen Geschäftsschritten entsprechen. Jede Eingabemethode erhält einen Status, mit dem sie arbeiten kann, hat jedoch nicht das Recht, sie zu ändern. Die Methode gibt möglicherweise einen Marker zurück und meldet:

, () ;
- , .

Es gibt komplexere Markierungen: Sie können bestätigen, dass der Status funktioniert, einige Teile des Geschäftsprozesses löschen oder ändern. Sie können auch in Klassen schreiben.

Story starten. Wie starte ich Story bei der Ausführung? Dies ist ein Geschäftsobjekt, das als Methode funktioniert: Wir übertragen Daten an die Eingabe, validieren sie und interpretieren die Schritte. Die laufende Story merkt sich den Ausführungsverlauf, zeichnet den Status auf, der im Geschäftsprozess darin aufgetreten ist, und gibt an, wer diesen Status beeinflusst hat .

Debug-Symbolleiste. Wenn wir in Django schreiben und das Debug-Panel verwenden, können wir sehen, welche Geschäftsszenarien in jeder Anfrage verarbeitet wurden und welchen Status sie haben.

Py.test. Wenn wir in py.test schreiben, können wir für den gefallenen Test sehen, welche Geschäftsskripte in jeder Zeile ausgeführt wurden und was schief gelaufen ist. Dies ist praktisch - anstatt den Code einzugeben, lesen wir die Spezifikation und verstehen, was passiert ist.

Wache. Noch besser, wenn wir den Fehler 500 erhalten. In einem regulären System lassen wir uns damit ab und beginnen zu untersuchen. In Sentry wird ein detaillierter Bericht darüber angezeigt, was der Benutzer getan hat, um den Fehler zu machen. Es ist bequem und angenehm, wenn um 3 Uhr morgens solche Informationen für Sie gesammelt wurden.

ELK . Jetzt arbeiten wir aktiv an einem Plugin, das all dies in Elasticsearch in den Kibana-Stack schreibt und kompetente Indizes erstellt.

Zum Beispiel haben wir einen Vertrag über den Status eines Geschäftsprozesses. Wir wissen zum Beispiel, was da istrelation IDBericht. Anstatt archaisch zu recherchieren, was einst dort passiert ist, schreiben wir eine Anfrage in Kibana. Es werden alle Geschichten angezeigt, die sich auf einen bestimmten Benutzer beziehen. Als nächstes untersuchen wir den Zustand innerhalb unserer Geschäftsprozesse und Geschäftsszenarien. Wir schreiben keine einzige Zeile Protokollierungscode, aber das Projekt wird auf der Abstraktionsebene protokolliert, auf der wir es sehen möchten.

Aber ich möchte etwas Höheres, zum Beispiel leichte Objekte. Solche Objekte enthalten gebildete Datenstrukturen und -methoden, die sich auf die Annahme von Geschäftsentscheidungen beziehen und beispielsweise nicht auf die Arbeit mit der Datenbank. Daher fahren wir mit dem nächsten Teil der modellgetriebenen Architektur fort - Entitäten, Aggregate und Wertobjekte.

Entitäten, Aggregate und Wertobjekte

Wie ist das alles miteinander verbunden? Zum Beispiel gibt ein Benutzer eine Produktbestellung auf und wir berechnen. Was ist die Wurzel der Aggregation und was ist ein einfaches Objekt?

Alles, was unterstrichen wird, ist die Wurzel der Aggregation. Damit möchte ich direkt arbeiten: wichtig, wertvoll, ganzheitlich.

Wo soll ich anfangen? Wir werden im Projekt ein leeres Paket erstellen, in das wir unsere Einheiten stellen. Aggregate werden besser mit etwas Deklarativem wie dataclassesoder geschrieben attrs.

Datenklassen . Wenn dataclasswir eine Art Aggregat angeben, schreiben wir mit NewType eine Anmerkung dazu . In der Anmerkung geben wir eine explizite Referenz an, die im Typsystem ausgedrückt wird. Wenn es sich dataclassnur um eine Datenstruktur (Entität) handelt, speichern Sie sie im Aggregat.

Im Kontext von Geschichten können nur Aggregate lügen. Der Zugriff auf etwas, das in sie eingebettet ist, kann nur über öffentliche Methoden und Regeln auf hoher Ebene erfolgen. Auf diese Weise können Sie logisch und kompetent ein Modell erstellen, über das wir mit Experten aus dem Fachgebiet zusammenarbeiten. Dies ist dieselbe einzelne Sprache .

Das Problem tritt sofort auf - Repositories. Ich habe eine Datenbank, mit der ich über Django arbeite, einen nahe gelegenen Microservice, an den ich Anfragen sende. Es gibt JSON und eine Instanz des Django-Modells. Daten empfangen und von Hand übertragen, nur um die Methode schön aufzurufen oder zu testen? Nein, natürlich. Dry-Python verfügt über eine Mappers-Bibliothek, mit der Sie Abstraktionen und Domänenaggregate auf hoher Ebene den Orten zuordnen können, an denen wir sie speichern.

Mapper

Wir fügen unserem Projekt ein weiteres Paket hinzu - ein Repository, in dem wir unser speichern werden mappers. Auf diese Weise übertragen wir Geschäftslogik auf hoher Ebene in die reale Welt.

Zum Beispiel können wir beschreiben, wie wir eines dataclasseinem Django-Modell zuordnen.

Django ORM. Wir vergleichen das Bestellmodell mit der Beschreibung von Django ORM - wir betrachten die Felder.

Zum Beispiel können wir einige Felder über die optionale Konfiguration neu schreiben. Folgendes wird passieren: mapperWährend der Deklaration wird verglichen, wie das dataclassModell geschrieben wird . Beispielsweise entsprechen Anmerkungen int(in Order dataclasseinem Feld costmit Anmerkungen int) im Django-Modell integer fieldder Option nullable="true". Hier wird es dataclassbieten hinzufügen optionalzu dataclass, oder zu entfernennullablevon field.

Über Mappers können Sie Funktionen hinzufügen, die etwas lesen oder schreiben. Leser sind Funktionen, die am Eingang ein Aggregat empfangen und einen Verweis darauf zurückgeben. Autoren machen das Gegenteil - Einheiten zurückgeben. Unter der Haube kann beispielsweise eine Anfrage an die Datenbank über Django erfolgen.

Swagger Definitionen Die gleichen Operationen können mit Microservices durchgeführt werden. Sie können einen Teil des Swagger-Schemas darauf schreiben und überprüfen, inwieweit das Swagger-Schema eines bestimmten Dienstes mit Ihren Domain-Modellen übereinstimmt. Außerdem wird die zurückgegebene Anforderung aus der Anforderungsbibliothek transparent in übersetzt dataclass.

GraphQL-Abfragen. GraphQL und Microservices: Das Schema des GraphQL-Schnittstellentyps funktioniert gut dagegendataclass. Sie können bestimmte GraphQL-Abfragen in interne Datenstrukturen übersetzen.

Warum sollten Sie sich mit dem internen Datenmodell auf hoher Ebene in der Anwendung beschäftigen? Um das „Warum“ zu veranschaulichen, werde ich eine „unterhaltsame“ Geschichte erzählen.

In einem unserer Projekte arbeiteten Web-Sockets über den Pusher-Service. Wir haben uns nicht darum gekümmert, wir haben es in eine Schnittstelle eingewickelt, um nicht direkt anzurufen. Diese Schnittstelle war in allen Geschichten gebunden und war zufrieden.

Die geschäftlichen Anforderungen haben sich jedoch geändert. Es stellte sich heraus, dass die Garantien, die Pusher für Web-Sockets bietet, nicht ausreichen. Beispielsweise benötigen Sie eine garantierte Nachrichtenübermittlung und einen garantierten Nachrichtenverlauf für die letzten 2 Minuten. Aus diesem Grund haben wir uns für den Ably Realtime-Service entschieden. Es hat auch eine Schnittstelle - wir werden einen Adapter schreiben und ihn überall binden, alles wird großartig. Nicht wirklich.

Die von Pusher verwendeten Abstraktionen (Funktionsargumente) sind in jedem Geschäftsobjekt eingeschlossen. Ich musste ungefähr 100 Geschichten reparieren und die Bildung des Benutzerkanals korrigieren, an den wir etwas senden.

Zurück zu den Tests.

Tests & Mocks

Wie testen Sie dieses Verhalten normalerweise mit externen Diensten? Wir machen etwas nass, wir beobachten, wie eine Bibliothek eines Drittanbieters aufgerufen wird, und das ist alles - wir sind sicher, dass alles in Ordnung ist. Wenn sich die Bibliothek ändert, ändern sich auch die Argumentformate.

Sie können eine Woche sparen, indem Sie Tausende von Tests und Hunderte von Geschäftsfällen neu schreiben, wenn Sie das Verhalten des internen Modells anders testen. Zum Beispiel ähnlich wie beim Integrationstest: Wir schreiben in den Benutzer-Stream und übersetzen diesen Stream bereits im Adapter, Pusher oder Ably in den Namen des normalen Kanals, um nicht alles in die Geschäftslogik zu schreiben.

Abhängigkeiten

In einer solchen Modellarchitektur erscheinen viele überflüssige Entitäten. Zuvor haben wir eine Art Django-Funktion übernommen und geschrieben: Anfrage, Antwort, minimale Körperbewegungen. Hier müssen Sie die Mapper initialisieren, Stories eingeben und initialisieren, die Anforderungszeile der HTTP-Anforderung verarbeiten und sehen, welche Antwort Sie geben müssen. All dies führt zu 30-50 Zeilen Boilerplate-Aufrufcode-Geschichten in der Django-Ansicht.

Andererseits haben wir bereits Schnittstellen und Mapper geschrieben. Wir können ihre Kompatibilität mit einem bestimmten Geschäftsfall überprüfen, beispielsweise mithilfe der Abhängigkeitsbibliothek. Wie? Durch das Abhängigkeitsinjektionsmuster wird alles deklarativ auf eine minimale Kesselplatte geklebt.

Hier geben wir die Aufgabe an, eine Klasse in das Servicepaket aufzunehmen, setzen Sie dreimappers, initialisiere das Stories-Objekt und gib es uns. Mit diesem Ansatz wird die Anzahl der Boilerplates im Code enorm reduziert.

Refactoring-Karte

Mit allem, worüber ich gesprochen habe, haben wir ein Schema entwickelt, mit dem wir ein großes Projekt von Django-Signalen (implizite "Rückruf-Hölle") mit DDD nach Django umgeschrieben haben.

Der erste Schritt ohne DDD . Zuerst hatten wir kein DDD - wir haben MVP geschrieben. Als sie ihr erstes Geld verdienten, luden sie Investoren ein und überzeugten sie, zu DDD zu wechseln.

Geschichten ohne Verträge. Wir haben das Projekt in logische Geschäftsfälle ohne Datenverträge unterteilt.

Verträge und Aggregate . Anschließend haben wir nacheinander den Datenvertrag für jedes Modell gezogen, der in unserer Architektur nachverfolgt werden kann.

Mapper . Mappers haben geschrieben, um Data Warehouse-Vorlagen loszuwerden.

Abhängigkeitsinjektion . Klebemuster loswerden.

Wenn Ihr Projekt aus MVP herausgewachsen ist und dringend in der Architektur geändert werden muss, damit es nicht in das Erbe übergeht, schauen Sie in Richtung DDD.

legacy Python-, , , Moscow Python Conf++ 27 . Python . unconference, , , , Drylabs.

DDD Python, TechLead Conf — IT-, DDD . 8 , Call for Papers 6 .

Domain Driven Design Tools