2016-07-25 33 views
-2

Wir haben eine alte und große PHP-Anwendung mit komplexer Geschäftslogik. Jetzt besteht das Projekt fast vollständig aus Spaghetti-Code. Ich plane eine reibungslose Migration mit Symfony, z. umschreiben Sie einige Funktionen mit Symfony. Auch scheint DDD eine gute Wahl für das Projekt zu sein. Die Grundidee besteht also darin, einige Features neu zu schreiben, um sie sauberer und einfacher zu warten. Irgendwelche Vorschläge?Symfony und DDD für ein altes und großes PHP-Projekt

Danke.

Antwort

0

DDD ist eine Reihe von Methoden zur Erleichterung der Teamkommunikation. Es hat weniger mit Refactoring und mehr mit Architektur zu tun.

-1

Ich weiß nicht, ob dies für SO geeignet ist, jedenfalls wäre die Erklärung riesig. Es gibt keine "Silberkugel" -Methode hier. Persönlich würde ich versuchen, Komponenten zu isolieren und diese einzeln zu einer oder mehreren neuen Symfony-Anwendungen zu migrieren.

DDD ist dort nicht relevant. Sie können viele nützliche Muster/Methoden in Martin Fowler Büchern finden, insbesondere "Refactoring" und "Patterns of Entreprise Architecture".

+0

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. –

+0

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

+0

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. –

4

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.

+0

Die Frage selbst, es ist definitiv schlecht für SO (zu allgemein, denke ich), aber ich bin froh, dass es zu einer so guten Antwort geführt hat. –