Herausforderung Brownfield, Teil 6: Partitionen durch Refaktorisierung evolvierbar machen
Nach der Identifikation der Core Domain einer Anwendung geht es in der Artikelserie zum Einsatz von Clean Code Developer in sogenannten Brownfield-Projekten nun darum, wie sich zusätzliche Features zielgerichtet und unabhängig vom bestehenden Code integrieren lassen.
- Stefan Lieser
- Ralf Westphal
Nach der Identifikation der Core Domain einer Anwendung geht es in der Artikelserie zum Einsatz von Clean Code Developer in sogenannten Brownfield-Projekten nun darum, wie sich zusätzliche Features zielgerichtet und unabhängig vom bestehenden Code integrieren lassen.
Der letzte Artikel der Serie empfahl, die Core Domain innerhalb der Anwendung zu identifizieren. Ziel dabei ist es, die Änderungen am Brownfield-System zu fokussieren. Statt wie mit der Gießkanne Refaktorisierungsmaßnahmen über das gesamte System zu verstreuen, sind die Autoren dafür, nur an den Stellen Änderungen vorzunehmen, an denen "die Musik spielt". Im Sinne der Theory of Constraints [1] stellt die Core Domain einen Engpass dar. Der Durchsatz des Unternehmens lässt sich nicht weiter erhöhen, als der Engpass das zulässt. Folglich ergibt sich der größte Nutzen für das Unternehmen, wenn es am Engpass ansetzt. Nur dann lässt sich der Durchsatz erhöhen. Auch bei der Betrachtungsweise der Core Domain als Engpass wird deutlich, dass hier eine Managemententscheidung gefragt ist
Die strategische Entscheidung, in welchem Bereich einer Anwendung Features zu ergänzen sind, kann für das Unternehmen weitreichende Folgen haben. Setzt ein Unternehmen auf das falsche Pferd, kann das im schlimmsten Fall seinen Untergang bedeuten. Insofern ist hier das Management gefragt, die Core Domain zu identifizieren, in der seiner Ansicht nach eine Fortentwicklung des Unternehmens am wahrscheinlichsten scheint.
Herausforderung Brownfield
Im Rahmen einer Artikelserie beleuchten die Initiatoren der "Clean Code Developer"-Initiative, Stefan Lieser und Ralf Westphal, die Herausforderungen an Clean Code Developer in Brownfield-Projekten.
- Teil 1: Was sind die Probleme?
- Teil 2: Das Sicherheitsnetz aufspannen
- Teil 3: Das Sicherheitsnetz erweitern
- Teil 4: Komplexität bewältigen durch Partitionierung
- Teil 5: Explizite Architektur als Ziel für Refaktorisierungen
- Teil 6: Partitionen durch Refaktorisierung evolvierbar machen
- Teil 7: Alle Veränderung in kleinen Schritten durchführen
Beim Identifizieren der Core Domain kann es zu den folgenden drei Situationen kommen (siehe auch den Exkurs zu Bounded Context/Partition als Begriffsklärung):
- Die Core Domain liegt innerhalb einer vorhandenen Partition.
- Die Core Domain liegt innerhalb einer neu zu erstellenden Partition.
- Die Core Domain liegt innerhalb eines neu zu erstellenden Bounded Context.
Für die praktische Umsetzung hat das Konsequenzen. In der Beratungspraxis treffen die Autoren nahezu ausschließlich auf die Annahme, dass die Änderungen oder Ergänzungen zwangsläufig in der vorhandenen (einzigen) Partition vorzunehmen wären. Die komplette Anwendung wird als eins betrachtet. Eine innere Struktur liegt nicht vor. Am Ende existiert eine einzige ausführbare Datei, ein Programm, in dem alle Funktionen untergebracht sind. Das ist der schwierigste Fall, denn er bedeutet, mitunter massive Änderungen am Code vornehmen zu müssen.
Schon der Gedanke, neben eine vorhandene Partition eine weitere zu stellen, steht bei vielen Entwicklerteams nicht auf dem Radar. Sie gehen meist davon aus, dass eine Anwendung immer aus einer einzigen Partition, sprich einem einzigen startbaren Programm, bestehen sollte. Der Gedanke, zusätzliche Features in einem anderen, völlig neuen Programm unterzubringen, fällt zunächst schwer. Doch das Aufteilen auf mehrere Partitionen schafft Freiräume, denn es reduziert drastisch die Notwendigkeit, Funktionen im Code zu ergänzen.
Die folgenden Abbildungen stellen die drei Möglichkeiten dar. Die erste zeigt die häufig vorzufindende Situation "alles ist eins". Alle Funktionen der Anwendung sind in einem einzigen Programm untergebracht. Ob das nun aus einem Executable besteht oder mehrere DLLs beteiligt sind, spielt keine Rolle. Eine wirkliche Trennung von Kontexten und Rollen findet nicht statt.
Die zweite Abbildung zeigt die Situation auf, wenn für zusätzliche Funktionen eine neue Partition innerhalb des bestehenden Kontexts begonnen wird. Dieser Schritt führt zu deutlich mehr Freiräumen, da die neue Partition neben der vorhandenen steht. Damit sind die Abhängigkeiten zu existierendem Code drastisch reduziert. Es handelt sich schon fast um ein Greenfield-Projekt. Lediglich die Abhängigkeit zu gemeinsam genutzten Ressourcen des Bounded Context bleibt bestehen.
In der dritten Abbildung ist zu sehen, welche zusätzlichen Freiräume durch einen weiteren Bounded Context entstehen. Die neuen Funktionen lassen sich dadurch ohne Abhängigkeiten zu bestehenden Ressourcen realisieren. Allerdings ist zusätzlich der Transport von Informationen zwischen den Kontexten zu implementieren.
