© Excellent backgrounds/Shutterstock.com
Kolumne: Knigge für Softwarearchitekten

Kolumne: Knigge für Softwarearchitekten


Eine der empfohlenen Entwicklungsmethodiken für Softwarearchitekturen ist Domain-driven Design ([1], [2], [3]). Dieses sieht vor, die Konzepte der Domäne, d. h. die Entities, die verarbeitet werden und die Services, die fachlich gebraucht werden, zuerst zu modellieren und dann möglichst unverändert eins zu eins im Sourcecode zu verankern. Das klingt einfach und fast selbstverständlich. Je stärker die Codestruktur mit der realen Welt übereinstimmt, desto leichter sind die Wartbarkeit und die Erweiterbarkeit der Software.

Abweichungen in der Praxis

„Historisch gewachsen“ sieht jedoch oft komplett anders aus. Ein Kundenverwaltungsprogramm (Abb. 1) bearbeitet eine Domänenentität „Kunde“ mit den wichtigsten Attributen wie Name, Adresse und Geburtsdatum. Ein später entwickeltes unabhängiges Programm zur Vertragsverwaltung erstellt sich eine Kopie der Entity „Kunde“ und fügt weitere Attribute hinzu, erlaubt aber auch Updates der kopierten Attribute ohne Zusammenhang mit der Kundenverwaltung. Schon sind Inkonsistenzen vorprogrammiert.

Ein drittes Programm zur VIP-Verwaltung wurde später geschrieben. Es regelt gemäß der Höhe der abgeschlossenen Verträge den Status des Kunden – von dem die ersten beiden Applikationen nichts mitbekommen. Für die komplette Kommunikation nach außen mit dem Kunden ist jedoch die Kundenverwaltung zuständig. Die wurde in der Zwischenzeit auch um den Service „Statusauskunft“ erweitert. Die VIP-Verwaltung enthält als Adresse nur die bevorzugte Versandadresse – ein neues Konzept, das wir letztes Jahr eingeführt haben, um die Kunden „besser zu betreuen.“

starke_1.tif_fmt1.jpgAbb. 1: Drei Programme, jedes modifiziert unabhängig Attribute

Jetzt beginnt das Chaos. Jedes Programm setzt und modifiziert unabhängig von anderen diese Attribute. Wahrscheinlich sind inzwischen viele Brückenprogramme und Adapter geschrieben worden, um den anderen Programmen von diesen Änderungen Kenntnis zu geben, damit keine Inkonsistenzen auftreten. Kommt Ihnen das bekannt vor? Hier betritt der Domäniker das Spiel und sorgt für Besserung.

Zielsetzung des Domänikers

Der Domäniker klärt als Erstes ab, wie das Domänenmodell – unabhängig von den heute existierenden Programmteilen – aussehen sollte. Welche wichtigen fachlichen Dinge müssen bearbeitet werden? Und welche Services sind für welche Entities notwendig? Dann beginnt die Sisyphusarbeit der eigentlichen Verbesserung: Wo überall im Sourcecode sind Teile dieser Entity verstreut, redundant vorhanden oder widersprüchlich benutzt?

Sche...

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