© tomertu/Shutterstock.com
Die strategischen und taktischen Vorteile von DDD nutzen

Legacy mit DDD verbessern


Legacy-Code treibt die Entwicklungskosten in die Höhe und führt dazu, dass wir diese alten Softwaresysteme nicht mehr gerne anfassen. Ist das unvermeidbar? Können wir etwas tun? Mit Domain-driven Design (DDD) haben wir ein Werkzeug zur Hand, um Legacy-Code Schritt für Schritt wieder in den Bereich beherrschbarer Wartungskosten zu bringen.

Seit über sechzig Jahren bauen wir Software, die immer größer und komplexer wird. Inzwischen haben wir nicht nur Mainframe-Altsysteme, auch die Systeme in objektorientierten Programmiersprachen sind in den letzten zwanzig Jahren so schnell und immer wieder unkontrolliert gewachsen, dass viele von ihnen zu einem großen Knäuel geworden sind. Domain-driven Design kann uns dabei helfen, Legacy-Systeme deutlich zu verbessern.

Wie entsteht schwer wartbarer Legacy-Code?

Gehen wir einmal davon aus, dass wir zu Beginn unseres Softwareentwicklungsprojekts eine qualitativ hochwertige, modulare Architektur entworfen haben. Dann kann man hoffen, dass sich unser Softwaresystem anfänglich gut warten lässt. In diesem Stadium befindet sich unser System also in dem Korridor geringer technische Schulden mit gleichbleibendem Aufwand für die Wartung (grüne Klammer in Abb. 1).

lilienthal_legacy_1.tif_fmt1.jpgAbb. 1: Entwicklung und Effekt von technischen Schulden

Der Begriff technische Schulden ist eine Metapher, die Ward Cunningham 1992 geprägt hat [1]. Technische Schulden entstehen, wenn bewusst oder unbewusst falsche oder suboptimale technische Entscheidungen getroffen werden. Diese falschen oder suboptimalen Entscheidungen führen zu einem späteren Zeitpunkt zu Mehraufwand, der Wartung und Erweiterung verzögert.

In der Diskussion um technische Schulden werden viele Arten und Varianten aufgeführt. Mit dem Fokus auf Domain-driven Design – und nicht auf Projektleitung, Anforderungsermittlung, Usability oder Hardware – möchte ich in diesem Artikel die Design- und Architekturschulden ins Zentrum rücken. Es geht also um technische Schulden, die ausdrücken, dass beim Design von Klassen, Paketen und Schichten die Grundprinzipien modularen Designs missachtet wurden: Kohäsion und Kopplung sowie das Single Responsibility Principle von Robert Martin [2]. Bei diesen technischen Schulden kann DDD wahre Wunder wirken, wie Sie im Laufe des Artikels erfahren werden. Aber bevor wir uns den Wundern von DDD zuwenden, schauen wir uns mit Hilfe von Abbildung 1 an, wie aus einem System mit einer qualitativ hochwertigen, modularen Architektur schwer wartbare Legacy werden kann.

Je länger unser System lebt, umso mehr erweitern wir es und fügen neue Funktionalität hinzu. Bleibt uns keine Zeit, bei diesen Erweiterungen auf den Erhalt der modularen Architektur zu achten, erodiert diese Architektur mit der Zeit immer mehr. Wir nehmen immer mehr technische Schulden auf (gelbe Pfeile in Abb. 1, die aus dem Korridor gleichbleibenden Aufwands herausgehen und dann rot werden) und nähern uns immer mehr dem Legacy-Code, der nur mit hohem, unplanbarem Aufwand zu warten ist.

Von unserem Umgang mit diesen technischen Schulden hängt es ab, ob wir entweder eine stabile Qualität der Software erreichen, oder ob sich die Architekturerosion immer weiter ausbreitet (Abb. 1). Die in Abbildung 1 dargestellte Situation macht diesen langsamen Verfall dadurch deutlich, dass die roten Pfeile immer kürzer werden. Im Verhältnis zu Zeit und/oder Budget schaffen wir immer weniger Funktionalität. Folgefehler sind immer schwerer nachvollziehbar, bis zu dem Punkt, an dem jede Änderung zu einer schmerzhaften Anstrengung wird.

Besser wäre es, wenn unser Management und wir akzeptieren würden, dass Softwareentwicklung ein ständiger Lernprozess ist, bei dem der erste Entwurf einer Lösung selten der endgültige ist. Eine Erweiterung im Korridor des gleichbleibenden Aufwands für Wartung führt also immer auch erst einmal zu mehr Schulden (gelber Pfeil „Wartung und Erweiterung“ in Abb. 1). Die Überarbeitung der Architektur (Architekturerneuerung, grüne Pfeile in Abb. 1 im Korridor „Gleichbleibender Aufwand für Wartung“) muss in regelmäßigen Abständen durchgeführt werden, wenn vermieden werden soll, dass Legacy-Code entsteht. Folgt man diesem Prinzip, läuft die Entwicklung in einer stetigen Folge von Erweiterung und Refactoring ab. Kann ein Team diesen Zyklus von Erweiterung und Refactoring dauerhaft verfolgen, wird das System im Korridor geringer technischer Schulden bleiben (gelbe und grüne Pfeile in Abb. 1 im Korridor „Gleichbleibender Aufwand für Wartung“).

Ist man erst einmal im Korridor hoher, unplanbarer Wartung angelangt, gibt es zwei Möglichkeiten, um aus dem Dilemma wieder herauszukommen: Das System wird durch ein Neues ersetzt (Zyklus in Abb. 1) oder der Legacy Code wird refaktoriert (rote und gelbe abwärts gerichtete Pfeile in Abb. 1).

Wir wollen in diesem Artikel schauen, wie DDD uns dabei helfen kann, unseren Legacy-Code zu refaktorieren und in den Korridor des gleichbleibenden Aufwands für die Wartung zurückzukehren. Ursprünglich wurde DDD von Eric Evans entwickelt, um Teams dabei zu unterstützen, ein neues Softwaresystem gut zu designen. Aber die grundsätzlichen Ideen für das strategische und das taktische Design lassen sich auch auf Legacy...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang