Einführung

Im ersten Artikel haben wir den Umfang der angegebenen Praktiken hervorgehoben, für welche Projekte sie angewendet werden können und für welche nicht.

In diesem Artikel möchte ich einen kurzen Überblick über die Grundprinzipien von DDD geben und meine persönlichen Erfahrungen mit deren Anwendung teilen. Wir werden detaillierter auf Kommunikations- und Strukturansätze mit Beispielen für deren Umsetzung eingehen.

Im folgenden Artikel werde ich mögliche Kombinationen der angewendeten Entwurfsmuster unter Berücksichtigung ihrer Implementierung aufschreiben und schließlich ein Beispiel für eine spezifische Implementierung eines kleinen Mikroservices geben.

DDD

Erinnern Sie sich an die frühere Definition:

Domain-Driven Design (DDD) ist ein Ansatz zur Softwareentwicklung zur umfassenden Befriedigung von Anforderungen, indem die Implementierung eng mit den wichtigsten Geschäftsmodellen verknüpft wird, die ständig weiterentwickelt werden.

Das Nachschlagewerk, das die Praxis des Aufbaus komplexer Systeme beschreibt, ist Eric Evans ' Domain Driven Dedign (Big Blue Book). Wenn Sie einen Übersichtsartikel zu diesem Thema lesen, wissen Sie bereits davon. Wenn Sie DDD in der Praxis verwenden, müssen Sie es lesen. Dies ist nicht das am einfachsten zu lesende Buch:

Die kanonische Quelle für DDD ist Eric Evans 'Buch. Es ist nicht das am einfachsten zu lesende in der Softwareliteratur, aber es ist eines dieser Bücher, die eine erhebliche Investition reichlich zurückzahlen.

Martin Fowler: 15. Januar 2014

Wenn Sie durch den Inhalt des Buches scrollen, erscheint es Ihnen nicht ganz strukturiert. Aber die Karte wird uns helfen.

Auf der Karte sind jene Praktiken, die wir heute betrachten werden.

Der Umfang der im Buch behandelten Praktiken ist riesig. Der Umfang der Praktiken, die außerhalb dieses Buches angewendet werden können, ist noch größer. Identifizieren Sie Ihre Ziele, bevor Sie zumindest einen Teil davon in Betrieb nehmen. Ich werde mein eigenes als Beispiel geben.

• Steigern Sie die Produktivität.
• Schreiben Sie verständlichen Code.
• Skalierung auf Softwareentwicklungsebene.

Einzelne Sprache

Softwareentwicklung führt selten zur Schaffung von etwas Neuem, in der Regel ist dies eine Simulation von etwas Bestehendem.

Ein Modell ist eine Darstellung eines realen Objekts, die nur die erforderlichen Eigenschaften und Funktionen enthält.

Wir können kein Softwareprodukt erstellen, das den gesamten Themenbereich abdeckt. Es ist möglich, nur den Teil davon zu reproduzieren, der die erforderliche Funktionalität reproduziert.

Ein gutes Beispiel für ein Modell wäre eine topografische Karte. Sie ist ein Geländemodell. Die Karte enthält keine Wiesen mit Feldern und Flüssen, sondern spiegelt nur die Position realer Objekte relativ zueinander wider.

Um ein klares und klares Modell für alle zu erstellen, müssen Sie dieselbe Sprache sprechen. Dies sagt uns nicht nur Eric Evans, sondern auch der gesunde Menschenverstand. Wenn Programmierer ihre Begriffe verwenden und ihren eigenen "Slang" verwenden, wird der erstere einfach nicht verstehen, was zu tun ist. In diesem Fall kann das Unternehmen die tatsächlichen Kosten für die Entwicklung des einen oder anderen „Features“ nicht realisieren. Wie oft haben Sie schon gehört: "Ja, es ist nur eine Schaltfläche zum Hinzufügen"?

Ihr Ziel als Systemdesigner sollte es sein, das maximale Verständnis des gesamten Teams voneinander zu erlangen. Wie erreicht man das? Fang an zu reden. Wenn Menschen beginnen, in einer engen Gruppe zu kommunizieren, haben sie bestimmte allgemein akzeptierte Begriffe. In verschiedenen Unternehmen ist der Prozess der Einführung einer gemeinsamen Sprache wahrscheinlich unterschiedlich. Dies kann entweder eine willensstarke Entscheidung oder ein demokratisches Verfahren sein. Die Sprache kann explizit angegeben werden und wird nicht explizit eingegeben. In diesem Fall beginnen sie einfach, sie zu sprechen. Eine gute Technik zur Einführung einer gemeinsamen Sprache ist die allgemeine Dokumentation.

So bewahren Sie die Projektdokumentation auf

1. Jede Kommunikation zwischen Geschäft und Entwicklung sollte Ihr Modell verbessern.
2. Notieren Sie nach dem Meeting das Ergebnis in Form einer Dokumentation (Scrum-Artefakt) und zeigen Sie diese Dokumentation allen Teilnehmern des Entwicklungsprozesses.
3. Verwenden Sie eine einzige Sprache in der Dokumentation.
4. Am wichtigsten: Verschwenden Sie keine Zeit mit der Dokumentation. Sie müssen noch Code schreiben, und die Dokumentation wird viele Male neu geschrieben. Das Ausgeben von Ressourcen ist teuer. Verwenden Sie eine Serviette, einen Stift und eine Kamera auf Ihrem Telefon, anstatt lange mit der UML-Diagrammanwendung herumzuspielen.
5. Dokumentation erfordert Disziplin, Sie können sie nicht von Zeit zu Zeit schreiben.
6. Trennen Sie die Dokumentation:
   
   • Kommentare im Code - Beschreiben Sie unverständliche Momente direkt im Code. Lassen Sie #ODO: (entfernen, wenn Sie den Code in den Master einfügen). Drücken Sie Ihre Meinung in den Kommentaren aus, zum Beispiel müssen Sie die eine oder andere Krücke verwenden, wenn Sie mit Legasy-Code arbeiten.
   • Kommentare zum Projekt README.md im Stammverzeichnis Ihres Projekts sollten technische Informationen enthalten: Starten des Projekts, Ausführen von Tests usw. Es ist auch eine gute Idee, eine Karte zu erstellen, auf der Sie alle Projekte haben und auf welchen Servern sie ausgeführt werden. Notieren Sie alle akzeptierten Vereinbarungen separat.
   • Und vor allem die Wissensbasis. Eine Sammlung von Dokumenten, die Geschäftsprozesse beschreiben. Dies ist der Teil der Dokumente, der sowohl Ihnen als auch dem Unternehmen zur Verfügung steht.
7. Der Hauptfehler derjenigen, die Dokumentation schreiben, ist Redundanz. Versuchen Sie nicht, alles und jedes abzudecken, sondern vermitteln Sie nur die allgemeine Bedeutung. Die Dokumentation sollte Ihr Projekt ergänzen, aber in keiner Weise ersetzen. Schreiben Sie nicht alle Begriffe auf, die nur mehrdeutig sind. Wenn eine Definition mehr als zwei Sätze umfasst, ist sie eine schlechte Definition.

Dokumentationsbeispiel:

 #         . # :  : -    - email -  ## : ###        ,     email  ,    1  (      email  ). ###           .          email . ###  email  email     .    ,    email.   . ###       ,     ,    .   . ###      email,    ,       .   2 . ###                  .    ,     ,             . 

Beachten Sie, dass wir in diesem Beispiel kein explizites Wörterbuch angegeben haben, das Konzept von Benutzer , Autorisierung und Registrierung jedoch korrigiert haben . Das Schreiben einer solchen Dokumentation dauert für den Experten nicht länger als 20 Minuten.

Für eine Person, die kein Experte auf dem Gebiet ist, wird der Prozess des Schreibens von Dokumentation als etwas Kompliziertes empfunden. Es ist notwendig, die Sammlung von Wissen und die Aufzeichnung des gesammelten Wissens zu trennen. != + .

"Was Sie das Universum nennen", sagte der vierte, "ist in der Tat eine Ansammlung von Welten, die wie die Haut eines Bogens übereinander liegen und allmählich voneinander getrennt werden."

- Ungewöhnlich klar gesagt! - bewunderte die Abderiten. - Erstaunlich klar! "Sie dachten, sie hätten den Philosophen verstanden, weil sie sehr gut wussten, was die Zwiebel war."

Aberdeen Story, Cristov Martin Wieland

Begrenzte Kontexte und Domänen

Stellen Sie sich vor, wir wären Designer eines progressiven Startups. Wir alle lieben gekühlte Pizza, fluchen mit Kurieren und füllen stundenlang Formulare auf der Baustelle aus. Deshalb haben wir uns ein wunderbares Startup „Vier Schildkröten und eine Ratte“ ausgedacht:

• Es gibt eine Seite, auf der Pizzerien registriert sind und ihre tatsächlichen Gerichte veröffentlichen.
• Diese Pizzerien haben keinen eigenen Kurierdienst.
• Es gibt Kunden, die die Pizzeria nicht erreichen können, aber bereit sind, eine Bestellung über die Website oder die mobile Anwendung aufzugeben.
• Killer-Feature: Kuriere sind keine speziell eingestellten Mitarbeiter, sondern normale Leute, die sich über die mobile Anwendung registriert haben
• Kuriere erhalten Befehle, nach ihrer Ausführung erhalten sie eine Bezahlung für die geleistete Arbeit.
• Das Warten auf solche Kuriere dauert länger, aber die Lieferung und dementsprechend die Pizza sind billiger.

Erinnern wir uns an die Dokumentation, die wir im vorherigen Kapitel beschrieben haben. Dort wurde in unserem einzigen Wörterbuch der Begriff Registrierung verwendet . Aber in diesem Projekt haben wir mehrere davon:

• Kundenregistrierung
• Pizzeria Registrierung
• Kurierregistrierung
• Bestellregistrierung

Eine einheitliche Sprache gehört zu einem begrenzten Kontext. Die Domäne der obigen Dokumentation ist "Autorisierungssystem". Versuchen wir, Domains für unser Startup zuzuweisen.

Bevor wir beginnen, schauen wir uns eine kleine Terminologie an, was eine Domain ist und was ein begrenzter Kontext ist.

Domain (Domain) - eine Darstellung einer realen Geschäftsstruktur, die ein bestimmtes Problem löst.

Zum Beispiel: Logistiksystem, Zahlungssystem, Autorisierungssystem, Auftragsverwaltungssystem.

Die Domain ist in Subdomains unterteilt, die kleinere Strukturen beschreiben, zum Beispiel: einen Auftragskorb, ein System zum Erstellen von Routen.

Jede Domain hat einen begrenzten Verantwortungsbereich - eingeschränkte Funktionalität.

Begrenzter Kontext - Eine Reihe von Domäneneinschränkungen, mit denen sich die Domäne auf nur eine Aufgabe konzentrieren kann, um die beste Lösung zu finden.

Ich möchte diesen Begriff als solche Abstraktion präsentieren. Eine Domain ist ein Kreis. Ein eingeschränkter Kontext ist ein Kreis.

Auch in der DDD-Terminologie wird der Kernel zugewiesen.

Der Kern (Kerndomäne) - die wichtigste Domäne, die Ihr Unternehmen am meisten charakterisiert.

Also, die Domänen des Projekts "Vier Schildkröten und eine Ratte":

Arbeit mit einer Pizzeria (Pizzarias)

Kontext : b2b alles was mit Pizzerien zu tun hat

Subdomains :

• Registrierung neuer Pizzerien
• Sortiment hinzufügen
• Aktualisieren des Status der Verfügbarkeit eines Produkts

Arbeiten Sie mit dem Kunden (Kunden)

Kontext : b2c, alles was mit der Arbeit mit Pizzakunden zu tun hat

Subdomains :

• Sortiment anzeigen
• Informationsmaterialien

Arbeit mit Kurieren (Liefersystem)

Kontext : b2e, alles was mit der Arbeit mit Kurieren zu tun hat

Subdomains :

• Kurierregistrierung
• Aufgabenverteilung
• Registrierung von Anträgen auf Abhebung von Geldern, die der Kurier verdient hat.

Bestellsystem

Kontext : Kernel. Ermöglicht die Koordination aller einzelnen Domains und bietet einen vollständigen Zyklus vom Eingang einer Bestellung bis zur Lieferung der Pizza an den Benutzer. Es ist kein Performer, sondern spielt die Rolle eines Dirigenten.

Subdomains :

• Auftragsannahme
• Auftragsausführung
• Auftragsstatusverfolgung

Abrechnungssystem (Abrechnung)

Kontext : Enthält alle Finanztransaktionen. Es bietet Interaktion mit dem Bearbeitungszentrum.

Subdomains :

• Geld für Bestellungen annehmen
• Kurieren Geld für geleistete Arbeit geben

Statistiksystem

Kontext : Das Sammeln und Verarbeiten (nicht Ausgeben) von analytischen Informationen.

Subdomains :

• Statistiken über Fonds
• Anwendungsstatistik

Managementsystem ( Management Panel)

Kontext : Die Ausgabe von analytischen Informationen. Toolkit für Managemententscheidungen.

• Analyse basierend auf gesammelten Statistiken
• Vormoderation von Zahlungen an Kuriere

Lassen Sie es uns anhand der Domains zuordnen.

Eine Domain Map (Context Map) ist ein grafisches Tool, mit dem Sie die Beziehungen zwischen einzelnen Domains beschreiben können.

Die Karte zeigt Links zwischen Domains. Diese Karte ist sehr oberflächlich, aber der Themenbereich ist nicht gut verstanden. Dies ist die erste Skizze, bei der Sie das erwartete Ergebnis erhalten.

Das Wichtigste auf der Karte ist, dass wir Verbindungen zwischen Domänen sehen. Eine solche Struktur passt sehr gut zur Microservice-Architektur:

Das Hauptprinzip der Microservice-Architektur: schwache Konnektivität und starke Haftung.

Dieses Prinzip wird in dem Buch von Sam Newman - Creating Microservices beschrieben . Dies ist das zweite Buch, das Sie lesen müssen, um die in diesem Artikel beschriebenen Ansätze in die Praxis umzusetzen. Was ist gemeint: Domänen sollten lose gekoppelt, aber intern eng miteinander verbunden sein.

Die Übersetzung dieser Begriffe stammt aus der offiziellen russischen Übersetzung und spiegelt möglicherweise die übermittelte Bedeutung nur schlecht wider. In den ursprünglichen Begriffen sind: Geringe Kopplung (Konnektivität, Eingriff, Griffigkeit, Konjugation), hohe Kohäsion (Konnektivität, Stärke).

Implementierungspraxis für die gemeinsame Nutzung von Domänen

Ich möchte meine persönlichen Erfahrungen teilen - eine Reihe von fundierten Entscheidungen. Ich fordere Sie nicht auf, diese Lösungen zu verwenden. Aber sie können eine gute Wahl sein, wenn Sie nicht wissen, wo Sie anfangen sollen. Mit persönlicher Erfahrung werden die Tools weiter auf Ihre Bedürfnisse zugeschnitten.

Die Hauptprinzipien, die uns geleitet haben:

• Die Einfachheit der Lösung. Machen Sie komplexe Dinge einfach, nicht einfach kompliziert.
• Pragmatismus Sie müssen immer die Situation betrachten und in Ermangelung einer vorhandenen Lösung eine neue entwickeln. Versuchen Sie, alles zu typisieren, aber vermeiden Sie Dogmatismus.
• Code! = Dokumentation. Der Code ist eine Anweisung für die Maschine, die Dokumentation ist eine Anweisung für Personen. Keine Notwendigkeit, sie zu verwirren und nacheinander herauszugeben.
• FEST

Wie implementiere ich Domains?

Es ist sehr praktisch, Domänen als separate Mikrodienste auszuwählen.

Microservices ist eine separate Anwendung, die die Logik einer Domäne implementiert.

In der DDD-Entwicklung ist das Prinzip der Zuordnung eines Mikrodienstes zu einer separaten Anwendung in einem begrenzten Kontext begrenzt. Dies negiert nicht das technische Prinzip der Trennung von Diensten (wenn dies auf die Notwendigkeit zurückzuführen ist, eine hohe Leistung sicherzustellen). Das Kontextprinzip wird jedoch dominant und bindend sein.

Wie kann die Beziehung zwischen Domänen hervorgehoben werden?

Beziehungen zwischen Domänen sind immer eine API. Es könnte RESTful json api, gRPC, AMPQ sein. Im Rahmen dieses Artikels werden wir kein Protokoll mit einem anderen vergleichen und ihre Vor- und Nachteile hervorheben, da jedes von ihnen seinen eigenen Anwendungsbereich hat. Lassen Sie uns dennoch auf allgemeine Empfehlungen eingehen:

Seien Sie flexibel bei der Auswahl eines Protokolls und starr in der Einheitlichkeit seiner Implementierung.

Wählen Sie ein Protokoll für jedes Domänenpaar einzeln aus. Versuchen Sie nicht, http überall zu verwenden. Möglicherweise benötigen Sie irgendwo asynchrone Warteschlangen, und die Vorteile von AMPQ werden für Sie offensichtlich. Ignorieren Sie diese Gelegenheit nicht, denn Sie haben überall RESTful.

Wenn Sie andererseits RESTful json implementieren, verwenden Sie einen Datenstrukturierungsstandard. Sie können zum Beispiel jsonapi oder openapi fertig machen. Wenn aus irgendeinem Grund vorgefertigte Lösungen nicht zu Ihnen passen und Sie das Gefühl haben, dass Sie Ihren Standard entwickeln, beschreiben und verwenden können. Aber verwenden Sie es überall, züchten Sie keine "Zoo" -Standards. Wenn Sie mit einem externen System kommunizieren müssen, das nichts über Ihre Standards weiß, schreiben Sie einen Microservice-Adapter.

Wie implementiere ich Subdomains?

Als separate Module innerhalb eines Microservices.

Ein Modul ist eine Implementierung einer Subdomain, indem Logik in einem separaten Namespace (Namespace) innerhalb eines einzelnen Microservices abgelegt wird.

Wie sieht das alles aus? Schauen wir uns ein Beispiel an. Wie wir uns erinnern, haben wir eine Liefersystemdomäne - diese Domäne hat drei Unterdomänen:

• Kurierregistrierung
• Ausgabe von Aufgaben (Aufgaben)
• Registrierung von Anträgen auf Abhebung von Geldern, die der Kurier verdient hat (Abhebung)
• Überprüfen, ob Ihr Microservice funktioniert, technisches Hilfswerkzeug (healt_checker)

Stellen Sie sich das alles in Form einer Ordnerstruktur vor:

 $ tree --dirsfirst delivery_system delivery_system ├── app/ │ ├── health_checker/ │ │ └── endpoints.rb │ ├── registrations/ │ │ ├── entities/ │ │ ├── forms/ │ │ ├── repositories/ │ │ ├── interactor/ │ │ ├── services/ │ │ ├── validations/ │ │ ├── endpoints.rb │ │ └── helpers.rb │ ├── tasks │ │ ├── entities/ │ │ ├── queries/ │ │ ├── repositories/ │ │ ├── endpoints.rb │ │ └── helpers.rb │ └── withdrawals │ ├── entities/ │ ├── forms/ │ ├── repositories/ │ ├── interactor/ │ ├── services/ │ ├── validations/ │ ├── endpoints.rb │ └── helpers.rb ├── config/ ├── db/ ├── docs/ ├── lib/ │ ├── schemas/ │ └── values/ ├── public ├── specs ├── config.ru ├── Gemfile ├── Gemfile.lock ├── Rakefile └── README.md 

Jeder Ordner im apps/ Verzeichnis implementiert die eine oder andere Unterdomäne. Innerhalb jeder Domäne gibt es verschiedene Muster: entities , forms , services usw. Wir werden jedes der angewendeten Muster in einem zukünftigen Artikel ausführlich betrachten.

Jedes dieser Muster ist im entsprechenden Namespace (Namespace) implementiert. Zum Beispiel ein Formular zum Erstellen eines Antrags auf Zahlung an einen Kurier:

 module Withdrawal #   module Forms #  class Create end end end 

Wie implementiere ich die Kommunikation zwischen Subdomains?

Schauen wir uns ein konkretes Beispiel an. Wir haben ein Kurierkonto: Registrations::Entities::Account . Es bezieht sich auf die Subdomain Registrations - da wir diese Domain nicht als Registrierungsprozess betrachten, sondern als Kontotabelle und Registrierungsbuch, wie in unserer Geschäftsdokumentation angegeben.

Wir haben zwei Prozesse, in deren Ausführung wir auf dieses Konto zugreifen.

• Konto erstellen (Registrierung)
• Erstellung eines Antrags auf Abhebung von Geldern, die von einem Kurier verdient wurden (Wihtdrawal)

Wie wir sehen, gehören diese beiden Prozesse zu verschiedenen Subdomänen - Registrierung und Wihtdrawal.

 module Registrations module Serivices class CreateAccount def call account = Entities::Account.new end end end end module Withdrwals module Serivices class CreateOrder def call account = Registrations::Entities::Account.new end end end end 

Im ersten Fall wird ein Aufruf der Klasse durch einen Aufruf von Entities::Account implementiert. Und im zweiten Fall durch einen expliziten Aufruf von Registrations::Entities::Account . Das heißt, Wenn wir explizit eine Subdomain angeben, stammt die Klasse aus einer anderen Subdomain und wir geben die Verbindung klar an.

Wenn die Klasse nicht explizit auf eine der Subdomänen angewendet wird, ist es sinnvoll, sie in den Ordner lib/ . In der Regel sind dies Klassen, die das 'ValueObject'-Muster implementieren. Wir werden dieses Muster in einem der folgenden Artikel genauer untersuchen.

Implementierung durch das Modell.

Um Eric Evans zu zitieren:

Wenn die Architektur des Programms oder zumindest ein zentraler Teil davon nicht der Struktur des Domänenmodells entspricht, ist ein solches Modell praktisch nutzlos, und die korrekte Funktionsweise des Programms sollte ebenfalls in Frage gestellt werden. Gleichzeitig sind zu komplexe Beziehungen zwischen Modellen und Funktionen in der Softwarearchitektur schwer zu verstehen und in der Praxis schwer aufrechtzuerhalten, wenn sich die Architektur ändert.

Erinnern wir uns an das Beispiel eines guten Modells, das ich bereits am Anfang dieses Artikels zitiert habe - eine topografische Karte. Unser Ziel ist es, schnell die Entfernung zwischen zwei Siedlungen zu finden. Wir könnten eine Referenztabelle verwenden, die zwei Punkte zwischen Städten zeigt. Und wir können die Karte benutzen. Sowohl dort als auch dort erhalten wir ungefähr zur gleichen Zeit das gleiche Ergebnis. Die Karte ist jedoch kompakter, zeigt den Themenbereich genauer an und ist universeller. Die Karte als Modell ist unglaublich ausdrucksstark. Und wenn wir es im Rahmen dieser Aufgabe betrachten, ist die Messung der Entfernung auf der Karte bequemer als auf dem Gebiet selbst, das sie widerspiegelt. Ein Modell, das einen Themenbereich widerspiegelt, kann ihn in einigen Eigenschaften übertreffen. Es ist wirklich unglaublich.

Die Implementierung des Modells ist immer ein kreativer Prozess mit unvorhersehbaren Ergebnissen. Die Qualität Ihres Codes ist weder seine Leistung noch seine Komplexität, sondern seine Einfachheit und Ausdruckskraft. Verbessern Sie es durch ständiges Refactoring, machen Sie es flexibel und schneiden Sie alles Unnötige ab. Trennen Sie die Ebene, die für die Geschäftslogik des Modells verantwortlich ist, von den Ebenen, deren Bedarf auf die technische Implementierung zurückzuführen ist. Wie wir das geschafft haben, wird später beschrieben.