Seite 4: Domain Debt

Inhaltsverzeichnis

Es handelt sich hier nicht um technische, sondern vielmehr um fachliche Schulden (Domain Debt). In den Codebasen dieser Welt schlummern Tonnen solcher Schulden. Die Softwareindustrie redet jedoch nur wenig darüber. Sie übernimmt viel zu wenig Verantwortung dafür. Dabei haben IT-Teams heute viele wirksame Methoden an der Hand, um fachliche Schulden zu verhindern oder ihnen zu begegnen.

Einige wie eine allgegenwärtige Sprache (Ubiquitous Languages) oder abgegrenzte Kontexte (Bounded Context) sind seit über 15 Jahren bekannt. Sie rückten vor allem in den letzten Jahren durch den Microservice-Trend wieder vermehrt in den Fokus. Die Aufteilung von Systemen in viele kleinere Teile erfordert in der Regel eine strikte Trennung von Funktionen unter fachlichen Gesichtspunkten.

Diese Trennung fördert oftmals allerdings das zuvor genannten Problem zu Tage. Bei nicht konsequent verfolgten fachlichen Schnitten werden (Teil-)Modelle von einem Kontext in einen anderen übernommen. Das zuvor genannte Fallbeispiel weist solche Aspekte auf. Hier hätten klarere Abgrenzungen der Modelle sicherlich geholfen. Genau den Vorteil bieten abgegrenzte Kontexte. Sie trennen die Anwendbarkeit eines
Domänenmodells klar und deutlich von anderen Kontexten. Zugleich gewährleisten sie somit eine konzeptionelle Integrität.

Ein großes Problem dieser Abgrenzung ist allerdings, dass eine Fachsprache oftmals nur kontextbezogen eindeutig ist. Schaut man sich das zuvor genannte Beispiel der Zugfahrten an, wird das deutlich. Von welcher Art Zugfahrt spricht man, wenn keine Kontextinformationen vorhanden sind? Daher ist es umso wichtiger, eine allgegenwertige Sprache zu etablieren und diese rigoros anzuwenden – von der Anforderungserhebung über die Dokumentation bis in den Code.

Dabei ist es wichtig zu verstehen, in welchem Kontext man sich grade bewegt. Das ist insbesondere für Entwickler schwierig, die oftmals mit mehreren Kontexten konfrontiert sind. Ein guter Teamschnitt oder soziotechnische Architekturpatterns können hier Abhilfe schaffen.

Von DDD lernen

Vielfach hilft es allerdings nur, das Big Picture mit allen Kontexten oder zumindest angrenzende Kontexte und deren Abgrenzungskriterien zu verstehen. Methoden wie Event Storming oder Domain Story Telling, die in den letzten Jahren vor allem in der DDD-Community (Domain-Driven Design) entstanden sind, sind ein hervorragendes Mittel, um dieses Verständnis in frühen Phase gemeinsam im Team zu erarbeiten. Sie sind aber auch auf unterschiedlicher technischer wie fachlicher Tiefe und iterativ, inkrementell anwendbar.

So hilft Event Storming als Form eines informellen, moderierten Workshops ein gemeinsames Verständnis des Domänenmodells zu schaffen und unter den beteiligten Personen zu teilen. Das wird vor allem durch Teilnahme möglichst vieler Interessensvertreter erreicht. Egal ob Entwickler, Product Owner, Projektleiter oder Fachexperte, alle sind gemeinsam an der Modellierung beteiligt. Die Modellierung erfolgt mit einer großen Menge Post-its an einer Wand. Dabei wird das Modell in der Regel vorwärts und rückwärts durchgegangen, um sicherzustellen, dass alle relevanten Punkte abgedeckt sind. Die Methode erlaubt es, mögliche auftretende Ereignisse, deren Auslöser, Informationen, Benutzer, externe Systeme bis hin zu zeitlichen Aspekten zu modellieren. So entsteht eine gemeinsame Ausrichtung des Entwicklungsteams mit den Fachexperten und eine gemeinsame Terminologie. Vielen Missverständnissen lässt sich auf diese Art einfach entgegenwirken und fachliche Schulden vermeiden.

Mit all diesen Methoden an der Hand ist es daher letztlich an der Zeit, dass die Softwareindustrie und jeder Einzelne (sei es Enwickler, Product Owner, Projekt Manager ...) seinen Teil an Verantwortung übernimmt, um fachlichen Schulden mindestens genau so zu begegnen wie technischen Schulden.

Sven-Torben Janus
ist mitverantwortlich für den Bereich Softwarearchitektur bei der Conciso GmbH. Er befürwortet einen agilen und praktikablen Entwurf von Softwarearchitekturen. Sein Unbehagen über technologiegetriebene Designs führte ihn zum Domain-Driven Design und zur Gründung des DDD Meetup Rhein/Main. (ane)