Einführung

In früheren Artikeln haben wir den Umfang des Ansatzes identifiziert und die grundlegenden methodischen Prinzipien des Domain Driven Design untersucht .

In diesem Artikel möchte ich die wichtigsten modernen Ansätze zum Aufbau der Architektur von Unternehmenssystemen skizzieren: Supple, Screaming, Clean und meine klare Interpretation in Form einer schlüsselfertigen Komplettlösung geben.

In Zukunft werden wir jedes Entwurfsmuster im Detail betrachten: Wir geben den Umfang an, geben Codebeispiele an und heben empfohlene Vorgehensweisen hervor. Als Ergebnis werden wir einen vorgefertigten Microservice schreiben.

Flexible Architektur

Im letzten Artikel haben wir uns auf die Tatsache konzentriert, dass DDD die Praxis der Implementierung durch das Modell beinhaltet. Der Themenbereich sollte durch Ihren Code beschrieben werden. Versuchen wir herauszufinden, wie das geht.

Eric Evans bietet in seinem Buch eine Reihe empfohlener Entwurfsmuster und bezeichnet diesen Ansatz als flexibel:

Im Namen der Architekturflexibilität wurden viele unnötige Konstruktionen in Programmen angehäuft. Übermäßige Abstraktionsebenen und indirekte Verknüpfungen stören eher als helfen in dieser Angelegenheit. Schauen Sie sich die Architektur an, die Programmierer wirklich dazu inspiriert, sie zu verfeinern, und Sie werden normalerweise etwas sehr Einfaches sehen. Einfach heißt aber nicht einfach auszuführen. Um solche Elemente zu schaffen, die zu komplexen Systemen zusammengesetzt werden können und gleichzeitig leicht zu verstehen sind, ist es notwendig, "Engagement" für das Entwerfen nach dem Modell mit einem ziemlich strengen Architekturstil zu kombinieren. Eine bestimmte Designfähigkeit ist nicht nur erforderlich, um etwas zu erstellen, sondern auch, um das fertige zu verwenden.

Eric Evans, Domain-Driven Design: Komplexität im Herzen von Software angehen

Die vorgestellten Entwurfsmuster sind keine strenge Architektur oder vorgefertigte Lösung, sondern Denkanstöße.

Auffällige Architektur

Ähnliche Gedanken kamen in den Köpfen vieler Entwickler und Designer komplexer Systeme auf.

Im Jahr 2011 wurde ein Artikel von Robert Martin - Screaming Architecture veröffentlicht, der besagt, dass Ihr Code den Themenbereich nicht nur beschreiben, sondern vorzugsweise obszön darüber schreien sollte.

Was schreit die Architektur Ihrer Anwendung? Wenn Sie sich die Verzeichnisstruktur der obersten Ebene und die Quelldateien im Paket der höchsten Ebene ansehen. schreien sie: Gesundheitssystem oder Buchhaltungssystem oder Bestandsverwaltungssystem? Oder schreien sie: Rails oder Spring / Hibernate oder ASP?

Robert C. Martin, 30. September 2011

Robert sagt, dass Ihr Anwendungscode die Aktivität der Anwendung widerspiegeln sollte, anstatt sich an die Regeln des Frameworks anzupassen. Die Framework-Struktur sollte Ihre Architektur nicht einschränken. Die Anwendung sollte wiederum nicht an die Datenbank oder das http-Protokoll angehängt werden. Dies sind lediglich Speicher- und Übermittlungsmechanismen. Der Begrenzungsrahmen ist ein Werkzeug. Sie sollten kein Anhänger des Frameworks werden. Die Tests Ihrer Anwendung sind Tests der Funktionslogik und keine Tests des http-Protokolls.

Saubere Architektur

Ein Jahr später der nächste Artikel von Robert Martin - The Clean Architecture . Darin erklärt der Autor, wie man den Code zum Schreien bringt. Nachdem er mehrere Architekturen studiert hat, identifiziert er die Grundprinzipien:

1. Rahmenunabhängigkeit. Die Architektur ist nicht von einer vorhandenen Bibliothek abhängig. Auf diese Weise können Sie Frameworks als Werkzeuge verwenden und nicht die Einschränkungen, die Ihre Hände binden.
2. Testbarkeit. Geschäftsregeln können ohne Benutzeroberfläche, Datenbank, Webserver oder andere technische Mittel getestet werden.
3. Unabhängigkeit der Benutzeroberfläche. Die Benutzeroberfläche kann einfach geändert werden, ohne den Rest des Systems zu ändern. Beispielsweise kann die Weboberfläche durch die Konsolenschnittstelle ersetzt werden, ohne die Geschäftslogik zu ändern.
4. Datenbankunabhängigkeit. Sie können Oracle oder SQL Server gegen Mongo, BigTable, CouchDB oder etwas anderes austauschen. Ihre Anwendungslogik sollte nicht datenbankgebunden sein.
5. Unabhängigkeit von Umwelteinflüssen. Tatsächlich wissen Ihre Geschäftsregeln einfach nichts über die Außenwelt.

Auf einem habr wurde bereits ein sehr guter Artikel Misconceptions Clean Architecture veröffentlicht . Sein Autor Jeevuz hat die Feinheiten des Verständnisses dieses Ansatzes sehr gut gekaut. Ich empfehle Ihnen dringend, sich sowohl mit ihm als auch mit den Originalmaterialien vertraut zu machen.

Variable Architektur

Die Beschreibung des obigen Ansatzes sieht nicht so einfach aus. Im Rahmen der Entwicklung der Architektur einer Reihe komplexer Unternehmenssysteme haben meine Kollegen und ich eine ziemlich klare Interpretation der beschriebenen Ansätze entwickelt, die ich im Folgenden vorstellen möchte.

Vor dem Aufkommen von Computern und Programmiersprachen wurde der Papierworkflow verwendet, um Systeme mit komplexer Geschäftslogik zu erstellen und zu verwalten. Das Ergebnis eines Prozesses war ein Dokument, das letztendlich ein bestimmtes Geschäftsobjekt beschrieb. Infolgedessen bestand der Papierkram aus drei einfachen Aktionen :

1. Dokumenterstellung
2. Dokumentenverarbeitung
3. Arbeiten Sie mit dem Archiv der Dokumente
4. Einreichung von Dokumenten

Dokument - Aufzeichnen von Informationen über wirtschaftliche Aktivitäten eines bestimmten realen Geschäftsobjekts.

Bitte beachten Sie, dass das Dokument selbst kein echtes Geschäftsobjekt ist, sondern nur sein Modell . Derzeit werden Papierdokumente durch elektronische Dokumente ersetzt. Ein Dokument kann eine Aufzeichnung in einer Tabelle, einem Bild, einer Datei, einem gesendeten Brief oder einer anderen Information sein.
Ich möchte das Word-Dokument in Zukunft nicht mehr verwenden, da es verwirrender sein wird, werden wir das Konzept der Entität aus der DDD-Terminologie verwenden. Sie können sich jedoch vorstellen, dass Ihr gesamtes System jetzt ein elektronisches Dokumentenverwaltungssystem ist, das vier einfache Aktionen ausführt.

1. Sammeln
2. Verarbeitung
3. Lagerung
4. Repräsentativeation

Aktion - eine strukturelle Aktivitätseinheit eines Geschäftsmodells; ein relativ abgeschlossener separater Akt eines bewussten Ziels, die Willkür und Intentionalität der individuellen Aktivität eines Geschäftsobjekts, die vom Endbenutzer unterschieden wird.

Ein gutes Beispiel für Action ist ein Theaterakt. Das Theater modelliert Ereignisse aus dem wirklichen Leben. Die Handlung ist ein bedeutender Teil des Stücks. Um die Geschichte zu vervollständigen, müssen Sie jedoch mehrere Akte in einer genau festgelegten Reihenfolge spielen. Eine solche Reihenfolge in unserer Architektur werden wir den Modus nennen .

Modus (Leitung) - Eine Reihe von Aktionen in einer bestimmten Reihenfolge, die eine vollständige Bedeutung haben und für den Endbenutzer von Vorteil sind.

Für solche Betriebsarten wurde ein selektiver Leiter oder Selektor erfunden. Genauer gesagt, "Zeitsteuerungsmechanismus zum Durchführen eines ausgewählten aus einer Vielzahl von Betriebssequenzen", für die das Patent US2870278A erhalten wurde. Wir kennen dieses Gerät als die "Drehung" der Waschmaschine. Die architektonische Wendung wird am Anfang des Artikels angegeben.

Die Variabilität des Ansatzes zeigt sich in der Tatsache, dass Sie mit dieser Architektur einen der vier Modi auswählen können, bei denen Sie keine unnötigen Aktionen ausführen.

Beim Starten der Waschmaschine können Sie den Modus auswählen: Waschen, Spülen oder Schleudern. Wenn Sie sich für das Waschen entscheiden, spült Ihre Maschine die Wäsche trotzdem aus und drückt sie dann zusammen. Mit der Spülung im Kit werden Sie sicher einen Spin bekommen. Schleudern - die letzte Aktion im Waschprozess ist die „einfachste“. In unserer Architektur ist die einfachste Aktion die Repräsentation , und wir werden damit beginnen.

Vertretung

Wenn wir von einer reinen Präsentation sprechen, ohne auf eine Datenbank oder eine externe Quelle zurückzugreifen, geben wir einige statische Informationen aus: eine HTML-Seite, eine Datei, ein Verzeichnis in Form von json. Wir können sogar nur eine Code-Antwort ausgeben - 200:

Schreiben wir den einfachsten "Health Checker"

module Health class Endpoints < Sinatra::Base get '/check' do; end end end 

In seiner primitivsten Form wird unser Schema folgendermaßen aussehen:

Arbeiten Sie mit dem Speichersystem

Unternehmen fordern die Verfügbarkeit Ihrer Anwendung. Warum sollte jemand Ihren Service benötigen, wenn wir ihn nicht zum richtigen Zeitpunkt nutzen können? Um die Datenintegrität sicherzustellen, zeichnen wir nach jeder Verarbeitung eine Änderung des Status eines Geschäftsobjekts auf.

Zum Abrufen eines Objekts aus dem Speicher ist kein Zugriff auf die Geschäftslogik erforderlich. Stellen Sie sich vor, wir automatisieren die Aktivitäten einer Hotelkette und haben ein Gastmagazin an der Rezeption. Wir haben uns entschlossen, Informationen über den Besucher zu sehen.

  module Reception class Endpoints < Sinatra::Base # Show item get '/residents/:id', provides: :json do resident = Repository::Residents.find params[:id] status 200 serialize(resident) end end end 

Arbeiten Sie mit dem Speichersystem in Form eines grafischen Diagramms:

Wie wir sehen können, wird die Kommunikation zwischen der für das Speichern verantwortlichen Schicht und der für die Darstellung von Daten verantwortlichen Schicht über das Antwortmodell implementiert. Dieses Modell gehört zu keiner dieser Ebenen. Tatsächlich ist dies ein Geschäftsobjekt und befindet sich auf der Ebene, die für die Geschäftslogik verantwortlich ist.

Verarbeitung

Wenn sich das Objektmodell aufgrund seiner Eigenschaften ändert, ohne neue Daten einzuführen, wenden wir uns direkt der Interactor- Ebene zu. Die Interactor- Schicht ist der Schlüssel in unserer Anwendung. Sie beschreibt die gesamte Geschäftslogik in Form separater Anwendungsfälle und ändert sich darauf.

Betrachten Sie diesen Anwendungsfall. Der Besucher ist bereits in unserem Hotel registriert, aber wir feiern jede Ankunft oder Abreise.

  module Reception class Endpoints < Sinatra::Base # Register resident arrival post '/residents/:uid/arrival', provides: :json do result = Interactors::Arrival.call(resident_id: params[:id]) check!(result) do status 201 serialize result.data end end # Register resident departure post '/residents/:uid/departure', provides: :json do result = Interactors::Departure.call(resident_id: params[:id]) check!(result) do status 201 serialize result.data end end end end 

Lass uns ein bisschen aufhören. Warum nicht die Implementierung zu einer einzigen Methode mit dem status ? Die Interaktoren für Arrival und Departure unterscheiden sich grundlegend. Wenn ein Gast zu uns kommt, müssen wir prüfen, ob die Reinigung beendet ist, ob neue Nachrichten für ihn eingegangen sind usw. Im Gegenteil, bei seiner Abreise müssen wir gegebenenfalls die Reinigung einleiten. Im Gegenzug erinnern wir uns nicht einmal an die Nachrichten, denn wenn er in einem Hotel gewesen wäre, hätten wir ihn sofort angerufen. Es ist all diese Geschäftslogik, die wir auf der Interactor- Ebene vorschreiben.

Aber was sollen wir tun, wenn wir Daten von außen haben? Hier ist die Aktion der Datenerfassung verbunden.

Daten sammeln

Bei der erstmaligen Anmeldung eines Gastes im Hotel füllt er das Anmeldeformular aus. Dieses Formular wird überprüft. Wenn die Daten korrekt sind, findet der Geschäftsprozess Registrierung statt. Der Prozess gibt Daten zurück - das erstellte Geschäftsmodell "Mandant". Wir präsentieren dem Gast dieses Modell in lesbarer Form:

 module Reception class Endpoints < Sinatra::Base # Register new resident post '/residents', provides: [:json] do form = Forms::Registration.new(params) complete! form do check! form.result do status 201 serialize form.result.data end end end end end 

Schematisch sieht es so aus:

Spielregeln (Regeln)

• In Bezug auf Prozesse ist ein variatives System in Aktionen unterteilt .
• Die Reihenfolge der Aktionen wird durch den Modus bestimmt .
• Die Modi sind inkrementell.
• Ein „komplexerer“ Modus ergänzt einen „einfacheren“ Modus für nur eine Aktion.
• Jede Aktion findet im Rahmen einer Ebene statt .
• Jede Ebene wird durch eine Klasse dargestellt .
• Innerhalb einer Ebene können sich Ebenenklassen und Verantwortungsklassen befinden .
• Die Kommunikation findet nur zwischen der Schicht und der Zwischenschichtklasse statt.
• Darstellungsmodelle sind Ausnahmen.
• Die Fehlerbehandlung sollte auf Klassenebene erfolgen .

Allgemeines Schema

Dieser Ansatz hat eine hohe Eintrittsschwelle. Die Anwendung erfordert viel Erfahrung des Designers, um die zu lösenden Aufgaben klar zu verstehen. Die Komplexität repräsentiert auch die Vielfalt der Auswahlmöglichkeiten des erforderlichen Werkzeugs. Trotz der Komplexität der Struktur ist die Implementierung auf Codeebene unglaublich einfach und ausdrucksstark. Obwohl es eine Reihe von Konventionen und Vollmachten enthält. In Zukunft werden wir jede Entwurfsvorlage einzeln analysieren, beschreiben, wie sie erstellt, getestet und der Umfang festgelegt wird. Und um nicht in ihrer Vielfalt verwirrt zu werden, wird eine vollständige Karte angeboten:

Hochauflösende Karte