Einführung
Ich möchte über die Erfahrungen bei der Anwendung von DDD-Praktiken auf ein vorhandenes Ruby on Rails-Projekt sprechen. Anfangs hatten wir einen Monolithen, der 10 Jahre lang geschrieben wurde. Die Hauptschwierigkeit des Projekts lag in recht komplexen Prozessen und einer hohen Konnektivität. Es ist uns nicht nur gelungen, die Anwendung in separate Dienste zu zerlegen, sondern auch die Lesbarkeit des Codes erheblich zu verbessern und die beschriebenen Prozesse transparent zu machen.
Das Lösen von Problemen innerhalb des Systems wurde vorhersehbar, wir hörten auf, mit der Black Box zu arbeiten, und am Ende begann das System selbst, uns zu Lösungen aufzufordern.
Um sowohl die Wahrnehmung als auch das Schreiben zu erleichtern, wird eine Geschichte über die verwendeten Ansätze in Form einer Reihe von Artikeln präsentiert. Dieser Ansatz ist kein "Wundermittel", daher möchte ich zunächst das Segment der Projekte hervorheben, in das diese Lösung passen kann. Darüber hinaus werde ich detaillierter auf die DDD-Methodik und die Implementierung dieses Musters im Mikroservice eingehen, die möglichen Kombinationen der angewendeten Muster unter Berücksichtigung ihrer Implementierung beschreiben und schließlich ein Beispiel für eine spezifische Implementierung eines kleinen Dienstes geben.
Thesaurus
Der Thesaurus ist ein Glossar mit Begriffen, die zur Beschreibung eines bestimmten Themenbereichs verwendet werden.
Alle Definitionen, die im Folgenden vorgestellt werden, sind im Rahmen dieses Artikels korrekt. Sie können sie auf Ihr Fachgebiet anwenden, wenn sie es gut genug beschreiben.
Das im Rahmen dieses Ansatzes gelöste Problem
Der nachfolgend beschriebene Ansatz ist eher eng spezialisiert und zielt vor allem auf die Lösung eines bestimmten Problems ab. Dies schließt jedoch ein mögliches Interesse von Fachleuten auf verwandten Gebieten nicht aus. Wir haben also die Aufgabe:
Sie müssen ein Projekt mit komplexer Geschäftslogik, das in Ruby on Rails geschrieben wurde, mit ausreichenden Ressourcen neu schreiben und verwalten.
Lassen Sie uns diese Aufgabe genauer schreiben.
Warum muss das Projekt neu geschrieben werden?
Ich denke, jeder Entwickler kann diese Frage beantworten. Es ist schwieriger zu antworten, damit diese Antwort die Anforderungen Ihres Unternehmens erfüllt.
Wir verwenden die Definition von Business , wie sie allgemein akzeptiert wird, obwohl wir in diesen Begriff ein breiteres Konzept investieren werden - ein Unternehmen (etwas, das von einer Gruppe von Menschen unternommen wird), Beruf (beschäftigt).
Geschäft ist die Anstrengung eines Unternehmens von Menschen, ausgedrückt durch Maßnahmen, die darauf abzielen, Vorteile für eine breite Palette von Einzelpersonen zu erzielen.
Zum Beispiel:
- Das Unternehmen stellt ein Produkt für Verbraucher her oder bietet eine Dienstleistung an.
- Das Labor entwickelt ein neues Medikament.
- Die Schule ist in der Ausbildung beschäftigt.
- Das Stadtarchiv informiert die Bürger.
- Lera erfreut ihre Fans mit einer hervorragenden Figur im sozialen Netzwerk.
Im Massenfall basiert ein Unternehmen auf der Idee, Gewinn zu erzielen, indem die Bedürfnisse seiner Kunden befriedigt werden. Um den Gewinn zu steigern, ist es notwendig, die tatsächlichen Bedürfnisse des Kunden mit einer Vielzahl hochwertiger Lösungen zu befriedigen. Diese Idee wird als das erste Prinzip des Agilen Manifests beschrieben, obwohl die Idee nicht neu ist. Die Tatsache, dass unserer Gesellschaft Bedürfnisse zugrunde liegen, wurde von vielen Philosophen argumentiert. Zum Beispiel versuchte Plato, die Bedürfnisse zu rationalisieren und ihre Klassifizierung zu erstellen. Er nennt die wichtigsten Formen wirtschaftlicher Bedürfnisse: Nahrung, Kleidung, Wohnen. "Die Herausforderung des Geschäfts" besteht darin, die Bedürfnisse zu befriedigen. Und die angewandten Lösungen sollten die Wettbewerbsfähigkeit des Unternehmens steigern.
Wettbewerbsfähigkeit - Der Vorteil eines Unternehmens gegenüber einem anderen.
Das Agile-Manifest gibt uns auch einen Hinweis darauf, dass die Projektflexibilität durch technische Exzellenz und Designqualität verbessert wird.
Betrachten Sie die Wertschöpfungskette am Beispiel eines "typischen Webprojekts".
- t 0 - wir haben eine Idee.
- t 1 haben wir MVP implementiert. Hier schweifen wir ein wenig ab:
MVP Minimum Viable Product - ein Produkt, das das Minimum hat, aber ausreicht, um die ersten Verbraucher zufrieden zu stellen. Die Hauptaufgabe besteht darin, Feedback für die Bildung von Hypothesen für die Weiterentwicklung des Produkts zu erhalten.
Der Begriff wurde von Steve Blank und Eric Rees populär gemacht. MVP ist ein effektives Tool, um Ihre Geschäftsidee zu testen und die Hauptfrage "Abheben - nicht abheben?" Zu beantworten.
- t 2 - Zurück zum Zeitplan. Die Idee war erfolgreich, wir erhielten positives Feedback und konnten zum angegebenen Zeitpunkt eine Vielzahl von Kundenbedürfnissen befriedigen.
- t 3 - Diesmal war die Zufriedenheit geringer. Wir haben das Personal aufgestockt.
- t 4 - Wir haben noch weniger Werte geliefert.
- t 5 - Wenn wir nicht mit dem Refactoring begonnen haben, ist das Geschäft zu diesem Zeitpunkt nicht mehr wettbewerbsfähig.
Warum passiert das? Im Laufe der Zeit sammelt unser Projekt aufgrund seiner hohen Konnektivität ein hohes Maß an Entropie. Angenommen, wir haben ein "typisches Unternehmen", das aus einer Abteilung für Marketing, Analyse, Logistik, Vertrieb und Management besteht. Im Moment ist das Projekt wie folgt:
Ich möchte sofort reservieren, dass Konnektivität nicht immer die Ursache für Entropie ist, sondern dass sie entsteht, wenn ein System mit einer großen Anzahl komplexer Geschäftsprozesse implementiert wird.
Eine Entropie im Code tritt immer dann auf, wenn die Geschäftsprozesse im Unternehmen nicht richtig aufgebaut sind. Was für beide jungen Unternehmen charakteristisch sein kann, die am Anfang ihres Weges stehen, ist auch charakteristisch für große Unternehmen, bei denen es unmöglich ist, alles auf einmal zu systematisieren. Dies ist ein natürlicher Prozess und wir sollten ihm nicht im Weg stehen, sondern ihn akzeptieren und anwenden. Kehren wir zum ersten Diagramm zurück und betrachten es von der anderen Seite:
Das Integral (der Bereich unter der Linie) ist das verdiente Geld. Die reale App (Real App) verdient mehr als das "Ideal" (Academin App), zumindest bis zum Einsetzen der Entropie - t 4 . Das hört sich gut an und das müssen Sie tun.
Aber was tun in Zukunft? Das wiederholte Refactoring bis ins Unendliche ist unmöglich. Irgendwann wird das Volumen der Codebasis ein solches Niveau erreichen, dass es schwierig sein wird, "alles auf einmal" neu zu schreiben. Und früher oder später wird es notwendig sein, das Projekt in separate Komponenten aufzuteilen:
Ein Ansatz zur Implementierung komplexer Systeme ist DDD:
Domain-Driven Design (DDD) ist ein Ansatz zur Entwicklung von Software zur umfassenden Befriedigung von Anforderungen, indem die Implementierung eng mit den wichtigsten Geschäftsmodellen verknüpft wird, die ständig weiterentwickelt werden.
DDD ist eine Reihe von Praktiken und Definitionen, die im nächsten Artikel ausführlicher beschrieben werden. Das zentrale Muster dieses Ansatzes ist der begrenzte Kontext , dessen Kern darin besteht, dass jeder Themenbereich aus mehreren Gruppen von Modellen besteht, die nicht mit der Außenwelt kommunizieren sollten, sowie aus Modellen, die in der Außenwelt zusammen mit anderen begrenzten Kontexten verwendet werden. Jeder begrenzte Kontext verfügt über eine klar definierte Schnittstelle, über die entschieden wird, welche Modelle in Verbindung mit anderen Kontexten verwendet werden sollen.
Dieses Muster kann über einen Namespace (Namespace) und über Microservices implementiert werden. Wir werden beide Implementierungen verwenden, abhängig von der Ebene der Kontextkonnektivität. Dies führt letztendlich zur Erstellung einer zerlegten, segmentierten Anwendung.
Es ist unwahrscheinlich, dass die obigen Grafiken das tatsächliche Bild widerspiegeln, aber Sie können verschiedene Ansätze untereinander vergleichen.
Projektunterstützung
Im Rahmen der Projektunterstützung müssen einige Dinge bereitgestellt werden.
- Wertlieferung : Scrum, Agile, Kundenservice, Kontinuierliche Lieferung.
- Entropiereduktion : DDD, Micro-Service als eine der Möglichkeiten zur Trennung von Kontexten, Dokumentation.
- Codequalität : Design auf Domänenebene, TDD, BDD.
- Produktqualität : Manuelle und automatisierte Tests, Fehlerverfolgung, Protokollierung.
- Produktverfügbarkeit : Vervielfältigungssysteme.
- Produktgeschwindigkeit : Horizontale Skalierung.
- Bindung des Entwicklungsteams : Motivationssystem, Offenheit, Ehrlichkeit.
Wie Sie sehen, erfordert die Wartung eines komplexen Systems eine große Menge an Ressourcen. Zuallererst hochqualifiziertes Personal. Überlegen Sie sich vor dem Einsatz dieser oder jener Technologie, ob Sie die Möglichkeit haben, ihre Unterstützung auf der richtigen Ebene bereitzustellen.
Es sollte beachtet werden, dass die Schwelle für den Eintritt in ein komplexes System ziemlich hoch ist, daher ist es wichtig, das Personal zu schulen. Wenn wir ohne Fehler arbeiten möchten, sollten wir keine "unersetzlichen" Spezialisten haben. Daher ist es notwendig, die vollständige Austauschbarkeit aller Rollen sicherzustellen. Wenn ein Spezialist für kontinuierliche Lieferung aus dem Team fliegt, müssen Sie ihn ersetzen. Wenn der Ersatz nicht bereitgestellt werden kann, lohnt es sich nicht, den Technologie-Stack ohne ausreichende Unterstützung in die "Produktion" einzuführen.
Hier geht es nicht um Spezialisten auf dem gleichen Niveau. Sie haben ein führendes DevOps und einen bestimmten Entwickler, für den dieses Thema interessant ist (die sogenannte "Multiklasse"). Für ihn wie für die "zweite Geige" ist es wichtig zu verstehen, wo und wie man Werkzeuge findet, um das Problem zu lösen. Zu diesem Zweck sollte mindestens ein Viertel des Gesamtvolumens der eingehenden Aufgaben im Zusammenhang mit der neuen Spezialität an diese verteilt werden. Diese Aufgaben werden langsam erledigt, die Kosten steigen, aber in Zukunft wird das Risiko einer Unterbrechung der Wertschöpfung aufgrund von Personalmangel vermieden.
Solche Dinge sind in den Anforderungen von Scrum beschrieben, ich möchte nicht darauf eingehen. Das einzige, worauf ich Sie aufmerksam machen möchte, worauf Sie vorbereitet sein müssen, sind die hohen Kosten, die für die Unterstützung Ihres Projekts aufgewendet werden. Wenn Ihr Unternehmen nicht dazu bereit ist und Sie viele teure Tools verwenden, werden Sie das Unternehmen ruinieren.
Kurz
- Wenn Sie MVP implementieren müssen, beginnen Sie mit Ruby On Rails.
- Wenn der MVP gestartet ist und die Idee gerechtfertigt ist, führen Sie das erste Refactoring durch, "erleichtern" Sie Ihre Modelle mit Diensten, Dekorateuren, entfernen Sie die Validierungs- und Datenbankebene aus den Modellen in separate Belange. Schreiben Sie Tests, Dokumentation.
- Wenn Sie kein so komplexes Projekt haben und Entropie durch Optimierung von Modellen entfernen können, tun Sie es.
- Wenn Sie ein logisches, lesbares Projekt haben und dessen Produktivität steigern müssen, während es beispielsweise nach Benutzern aufgeteilt werden kann, verwenden Sie die Skalierung. Versuchen Sie jedoch nicht, das Projekt nach Domänen in Dienste aufzuteilen.
- Wenn Sie ein „komplexes“ Unternehmen haben und nach einem Tool suchen, mit dem Sie online gehen können (warum haben Sie es noch nicht getan?!), Sollten Sie auch vorgefertigte „Unternehmenslösungen“ in Betracht ziehen, beispielsweise in Java oder .NET. Die beschriebenen Vorgehensweisen sind auf solche Lösungen zurückzuführen und verfügen über ein umfangreiches Toolset von der Stange, mit dem Sie Geld sparen können.
- Wenn Ihr Projekt auf Ruby ist, Sie Mitarbeiter von Ruby-Programmierern haben, das Projekt komplexe Geschäftslogik enthält, sich auf das Laden vorbereitet oder bereits geladen ist und die Entropie so stark gewachsen ist, dass das Umschreiben sehr, sehr schwierig ist, sollten Sie die Verwendung des DDD- und Microservices-Ansatzes in Betracht ziehen.
Das nächste Mal möchte ich die Essenz des DDD-Ansatzes und seine Implementierung von Mikroservices genauer betrachten.
Inspirationsquellen: