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

Neugierig geworden?

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