Herausforderung Brownfield, Teil 5: Explizite Architektur als Ziel für Refaktorisierungen

Inhaltsverzeichnis

In der Brownfield-Serie wurde bereits der "Big Ball of Mud", der große Klumpen Matsch, in Partitionen und Bounded Contexts zerlegt. Durch die Zerlegung fällt es leichter, mit der Sanierung des Systems zu beginnen. Das liegt vor allem daran, dass nun nicht mehr das Gesamtsystem auf einmal in den Blick zu nehmen ist, sondern sich einzelne Bounded Contexts oder Partitionen betrachten lassen. Nun erfordern die beschränkten Ressourcen Fokussierung.

Ein Unternehmen sollte aus betriebswirtschaftlicher Sicht ein Ziel vor Augen beziehungsweise eine Strategie entwickelt haben. Das mögen im einen Jahr zusätzliche Funktionen sein, von denen man sich ein weiteres Abheben von der Konkurrenz erwartet. Im anderen Jahr mag es angezeigt sein, Kosten zu reduzieren, in dem das Unternehmen den Support dadurch entlastet, dass es die Probleme beseitigt, die die meisten Ressourcen im Support binden.

Mehr Infos

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

Wie auch immer die Strategie aussieht, ist ohne ein solches Ziel die Sanierung von Brownfield-Projekten zu wenig fokussiert. In der Folge droht die Gefahr, dass an allen möglichen Stellen gearbeitet wird, ohne zu berücksichtigen, welche Auswirkungen das auf die weitere Entwicklung des Unternehmens hat. Die Unternehmensführung ist demnach gefragt, konkrete Vorgaben zu formulieren.

Kategorisierung à la Domain Driven Design

Hilfreich ist eine Einteilung der Anwendungsbereiche in drei Kategorien:

• General Domain
• Supporting Domain
• Core Domain

Diese Kategorisierung findet sich im Abschnitt "Strategic Design" in Eric Evans' Buch "Domain Driven Design" [1]. Im Bereich der General Domain liegen Aufgabenstellungen, die so häufig in Softwareprodukten anfallen, dass man sie "von der Stange" einkaufen kann. Als Beispiel sei der Bereich Buchhaltung genannt. In den meisten Fällen wird es für ein Unternehmen nicht sinnvoll sein, den Bounded Context Buchhaltung selbst zu entwickeln. Dabei würde man Entwicklerressourcen binden, ohne dadurch einen Wettbewerbsvorteil zu erlangen.

Im Bereich der Supporting Domain liegen Aufgabenstellungen, bei denen eine Eigenentwicklung sinnvoll sein kann, es aber auch denkbar ist, die Funktionen hinzuzukaufen. Im Einzelfall ist dann genau zu prüfen, ob es strategisch vorteilhaft wäre, den Bereich in die Hand zu nehmen, möglicherweise auch nur teilweise, indem man zugekaufte Komponenten anpasst. Beispielsweise seien UI Controls genannt, bei denen es zu aufwendig wäre, sie selbst zu entwickeln. Liegt das strategische Ziel eines Unternehmens jedoch darin, die Bedienbarkeit seiner Anwendungen von der der Mitbewerber abzuheben, mag es sinnvoll sein, die Controls selber zu entwickeln.

Im Bereich der Core Domains spiegelt sich die strategische Entscheidung des Unternehmens für den Bau eines Systems wieder. Da es strategische Entscheidungen regelmäßig anpasst, bleibt auch die Core Domain nicht konstant. Deren Fokus ändert sich im Laufe der Zeit. Kann ein Unternehmen einen Wettbewerbsvorteil erlangen, indem es innerhalb des Gesamtsystems etwas auf eine bestimmte Art und Weise tut, definiert das die Core Domain. Mit der Zeit werden die Wettbewerber den Vorteil vielleicht aufholen oder beginnen, die Dinge zu kopieren oder zumindest Ähnliches zu tun.

Als Verdeutlichung dessen sei an eine Textverarbeitung ohne Silbentrennung gedacht. Das Unternehmen, das als Erstes die Silbentrennung in die Textverarbeitung integriert, hat dadurch gegenüber den Mitbewerbern einen Vorteil. Die Silbentrennung stellt demnach die Core Domain dar. Allerdings werden die Konkurrenten nach und nach ebenfalls eine Silbentrennung ergänzen, womit sich diese aus der Core- in die Supporting Domain verschiebt. Nach einiger Zeit ist Silbentrennung etwas so Generisches, dass sie niemand mehr selbst entwickelt, sondern jeder eine der vielen Implementierungen verwendet.