Tatsächlich können die DDD-Prinzipien im Zusammenhang mit einem Legacy-Code-Basis-Refactoring angewendet werden. Dies ist, wie wir das gemacht haben (und tun es noch), aber nehmen Sie es nicht als Königsweg:
Phase 1 - Strategische Vorbereitungen:
1.) Verwenden Sie Context-Mapping identifiziert Begrenzte Kontexte und ihre Integrationen. Versuchen Sie zu Ihrer aktuellen Architektur agnostisch zu sein. Dies ist eigentlich sehr schwer wegen Voreingenommenheiten zu tun. Es ist praktisch, wenn Sie es mit Leuten machen, die keine ständigen Benutzer des alten Systems sind.
2.) sortieren Kontexte von strategischem Wert und identifizieren Sie Ihre Kerndomäne (Wo ist das Geld?), Schließlich Sub-Domains Unterstützung finden (Teile des Systems, die die Erreichung Ihrer strategischen Ziele) und unterstützt Generika Unterdomänen (Dinge, die absolut notwendig sind, dh Compliance und Accounting).
3.) Bringen Interessengruppen, Entwickler und Product Owner zusammen eine gemeinsame Sprache zu bilden, die Ubiquitous Sprache innerhalb der verschiedenen Domains, die die Absichten und Fähigkeiten des Unternehmens erfassen. Seien Sie dogmatisch über ein zentrales Wörterbuch dieser Begriffe, wenn Sie während der Diskussionen etwas mehrdeutiges hören, lösen Sie es auf und fügen Sie es dem Wörterbuch hinzu. Dies ist ein wesentlicher Bestandteil jedes DDD-Projekts, da wir die Fähigkeiten des Unternehmens modellieren, was bedeutet, dass der Code und die Stakeholder-Sprache die gleiche Semantik tragen sollten.
4.) OTPIONAL: Abhängig von der Größe und den Arbeitsmethoden Ihrer Organisation müssen Sie diese möglicherweise neu strukturieren.Lassen Sie Conway's Gesetz arbeiten für Sie und erstellen Sie eine bestimmte Funktion Schwerkraft durch die Neuzuordnung von Teams und Einzelpersonen zu den verschiedenen Domänen, die Sie zuvor als Wert Ströme identifiziert haben, wo die besten und hellsten sollte auf der Core Domain arbeiten. Ermöglichen Sie direkte Kommunikationsschnittstellen zwischen Entwicklern und Stakeholdern, um eng an der Spezifikation zu arbeiten und das Modell kontinuierlich zu destillieren.
Phase 2 - Umsetzung:
0.) Wenn Sie keine Erfahrungen mit solchen komplexen Refactoring haben, erhalten Hilfe von außen (Berater) oder erfahrene Ingenieure einzustellen, die zuvor getan haben. Glaube mir, du wirst es brauchen (ich habe es selbst auf die harte Tour gelernt).
1.) Erstellen Sie einen Bubble Context, in dem Sie Ihre Modelle neu entwerfen und in das Legacy-System integrieren können. Es gibt viele Integrationsmuster (Sie finden eine schöne Zusammenfassung dieser Muster here und here. Fragen Sie sich immer, ob der betreffende Kontext genügend strategischen Wert hat und sich mit der Zeit weiterentwickeln wird und in Zukunft auf Veränderungen reagieren muss Am Ende. geht es um Software zu schaffen, die einfach zu ändern und Refactoring ist. Iterate, spült und wiederholen. Immer den neuen Code Refactoring so früh wie neue Erkenntnisse aus der Wirtschaft zu gewinnen.
HINWEIS: Versuchen Sie nicht, zu viel zu tun: Die Bounded Context spielen sehr gut als Microservices Grenzen, aber oft unterschätzen Menschen die Komplexität eines verteilten Systems. Wenn Sie nicht die Verfügbarkeits- und Leistungsanforderungen haben, die diese Architektur erfordern würden, dann kann ein gut konzipierter, modularer Monolith genau das richtige Werkzeug sein, um die Dinge zu erledigen.
EDIT
Wenn Sie in den strategischen Teil DDD interessiert sind Sie MUST Uhr Paul Rayner Vortrag von DDDEU 16 here.
DDD/kann/sehr relevant für breit angelegte Refactoring sein. Die vorhandene Codebasis, selbst in einem nichtkonsistenten Zustand, kann verwendet werden, um Verhaltensweisen zu extrahieren und gültige Testszenarien zu erstellen, wenn eine Domäne modelliert wird. Die beiden Systeme können nebeneinander existieren, durch eine Reihe von Abstraktionen, die es Ihnen ermöglichen, die Domäne aus einem Aggregat nach dem anderen aufzubauen. Es ist letztlich nicht anders als ein begrenzter Kontext. Die Isolierung des Kontexts macht es zu einer idealen Methode, um einen Brownfield-Refactor aufzubauen. –
Ihre Beispiele sind gültig, aber ein solcher Ansatz ist viel weniger über DDD als viele andere Strategien: Wie erstellt man Tests, wie identifiziert und impliziert man Geschäftsinteressenten (in einer Webagentur ist dies eine große Sache), Refactoring-Methoden ... Letztlich wird DDD bei einem solchen Projekterfolg gegenüber allen anderen Methoden eine untergeordnete Rolle spielen. IMO dann sollte DDD nicht das erste Ding sein, das angeschaut wurde. – romaricdrigon
Daher meine betonte Verwendung von "/ can /". Ohne vor Ort zu sein, kann keiner von uns definitiv sagen, was der Wert ist, aber DDD bezieht sich genauso auf die strategischen Muster wie die taktischen Muster. Mein Punkt war, wenn ein Unternehmen den Wert des Refactorings aus welchem Grund auch immer gesehen hat und wenn das Team Interesse an DDD bekundet hat, ist es unangebracht, es sofort abzuweisen. Unternehmen haben eine geringe Toleranz gegenüber der Einführung mehrerer Refactors für ein einzelnes Projekt in diesem Maßstab.Einfaches Verschieben von Verhaltensweisen in das Domänenmodell hat große Auswirkungen, um die Komplexität zu reduzieren. –