Kolumne

Knigge für Softwarearchitekten: Der Domäniker

Gernot Starke, Peter Hruschka

© Shutterstock/kentoh

Eine der empfohlenen Entwicklungsmethodiken für Softwarearchitekturen ist Domain-driven Design (Literatur dazu siehe hier, hier und hier). 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.“

Abb. 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?

Scheibchenweise aufräumen

Idealerweise haben wir nur eine Stelle in all den Programmen, die fachliche Attribute setzt. In unserem Beispiel wäre es wünschenswert, alle Daten und Services von „Kunde“ zentral zu verwalten und zu pflegen. Andere Programme sollten auf diese Informationen nur über saubere Schnittstellen zugreifen.
Nicht immer lässt sich diese Redundanzfreiheit erreichen. Aber wenn schon (aus Performanzgründen oder wegen lokaler Verfügbarkeit) die Daten redundant (= kopiert) vorhanden sein sollen, dann sorgt der Domäniker für klare Verantwortungen und Spielregeln. Wer darf wann und wie ändern? Wen muss er darüber informieren, um Integrität zu sichern? Lassen sich Zugriffe einschränken auf „nur lesend“ statt „lesend und schreibend“? Und diese Spielregeln werden systematisch in die vorhandenen Programme eingebaut.

Reale Beziehungen ernst nehmen

Kennen Sie diesen Telefondialog? Sachbearbeiter: „Geben Sie mir bitte Ihre Kundennummer.“ Kunde: „Ich habe nur die Vertragsnummer. Da steht keine Kundennummer darauf.“ Sachbearbeiter: „Unter der Vertragsnummer kann ich leider nicht suchen. Ich brauche Ihre Kundennummer.“ Kunde: „Grrrr …“
In dem obigen Beispiel existiert im wahren Leben eine Beziehung zwischen Kunden und Verträgen. Beziehungen sind in der Mathematik richtungslos. Man kann also entweder für einen Kunden Verträge suchen oder für einen Vertrag den Kunden finden wollen. Wenn diese Symmetrie in der Software nicht verankert ist, führt das oft zu schlechter Benutzbarkeit und zu aufwändigen Suchverfahren. Der Domäniker erforscht anhand des Domänenmodells alle Beziehungen und die Häufigkeit der Benutzung in den unterschiedlichen Richtungen. Daraus leitet er dann systematisch die beste Art der Implementierung für diese Beziehungen ab.

Refactoring von Services

Der Domäniker bewegt schrittweise Services dorthin, wo sie fachlich am ehesten hingehören. Also alle normalen Kundenservices, wie Anlegen, Löschen, Stammdaten ändern etc. zur Kundenverwaltung, alle VIP-Services (Statusverwaltung, Upgrades, Sonderangebote etc.) zur VIP-Verwaltung. Und die Verknüpfung zwischen den beiden Programmen sollte wirklich reibungslos sein, wie Sie sich das als außenstehender Kunde dieser Firma wünschen. Auskünfte wie „Dazu muss ich leider das Programm wechseln – und das dauert. Bleiben Sie bitte in der Leitung“ sollten bald der Vergangenheit angehören. Mehr Beispiele für verkorkste Domänenmodelle finden Sie hier.

Fazit

In bestehenden Anwendungen finden sich Domainkonzepte oft nicht eins zu eins im Sourcecode wieder. Der Domäniker versucht, diese Diskrepanz nach bestem Wissen und Gewissen und nach den zur Verfügung stehenden Möglichkeiten zu beseitigen. Jede Annäherung an die ideale Domänenstruktur und jede Korrektur der Abweichung davon erhöht die zukünftige Wartbarkeit und Erweiterbarkeit – ein Aufwand, der sich mittelfristig auf jeden Fall bezahlt macht.

Aufmacherbild: Business Integration as Concept in a Application von Shutterstock / Urheberrecht: kentoh

Geschrieben von
Gernot Starke
Gernot Starke
    Informatikstudium an der RWTH Aachen, Dissertation über Software-Engineering an der J. Kepler Universität Linz. Langjährige Tätigkeit bei mehreren Software- und Beratungsunternehmen als Softwareentwickler, -architekt und technischer Projektleiter. 1996 Mitgründer und technischer Direktor des „Object Reality Center“, einer Kooperation mit Sun Microsystems. Dort Entwickler und technischer Leiter des ersten offizielle Java-Projekts von Sun in Deutschland. Seit 2011 Fellow der innoQ GmbH.  
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: