Domain-driven Design erklärt
Softwareentwicklung scheitert häufig nicht an der Technik, sondern an interdisziplinärer Kommunikation. Da Entwickler und Fachleute mit unterschiedlichen Terminologien arbeiten, gibt es Verständnisprobleme.
- Golo Roden
Softwareentwicklung scheitert häufig nicht an der Technik, sondern an interdisziplinärer Kommunikation. Da Entwickler und Fachleute mit unterschiedlichen Terminologien arbeiten, gibt es Verständnisprobleme.
Einer der faszinierendsten Aspekte der Softwareentwicklung ist der stetige Wandel. Daher gehört die regelmäßige Weiterbildung für viele Entwickler zum Alltag. Thematisch geht es dabei nicht nur um Techniken, sondern immer häufiger auch um Konzept- und Methodenwissen, Soft Skills und gegebenenfalls Führungsqualitäten. Einzig um das domänenspezifische Fachwissen ist es zumeist schlecht bestellt.
Entwicklern kann man deshalb allerdings vermutlich kaum etwas vorwerfen. Das hohe Tempo der Branche bedingt bereits eine enorme Spezialisierung in puncto Technik, beispielsweise im Hinblick auf Sprachen, Frameworks und Plattformen. Da viele Unternehmen die IT zudem fälschlicherweise nicht als strategisch wichtig ansehen, ist ein Wechsel des Arbeitsplatzes in der Regel mit einer neuen Fachdomäne gleichbedeutend. Häufig kommt daher die Frage auf, wozu das mühsame Einarbeiten in ein Thema nützt, das vermeintlich nicht von primärer Bedeutung für die eigene Arbeit ist und ohnehin in einigen Jahren hinfällig sein wird.
Softwareentwicklung ist kein Selbstzweck
Viele vergessen über all dem, dass Softwareentwicklung kein Selbstzweck ist, sondern in der Regel lediglich dazu dient, ein fachliches Problem zu lösen. Einer der zentralen Aspekte für eine fachlich korrekte Implementierung ist dabei das Verständnis der Thematik und der dazugehörigen Fachsprache. Genau die ist häufig allerdings nicht eindeutig definiert. Das führt in interdisziplinären Teams zu Kommunikationsproblemen, was in Verständnisschwierigkeiten zwischen Entwicklern und Fachabteilung und letztlich unnötigem Entwicklungsaufwand und Frust enden kann.
Wie schwierig es ist, unterschiedliche Sprachen zu vereinen, zeigt das Beispiel der Industrie 4.0. Während die Problemsprache häufig industriegetrieben ist, bewegt sich die Sprache der zugehörigen Lösung im digitalen Raum. Zahlreiche Unternehmen, die in der realen Welt mit klassischen Geschäftsmodellen ausgesprochen erfolgreich sind, gelingt die digitale Transformation deshalb entweder gar nicht oder nur äußerst schwerfällig.
Es wäre wünschenswert, die sprachliche Kluft zwischen Entwicklern und den fachlich getriebenen Domänenexperten zu überwinden, um sich gemeinsam auf die eigentliche Aufgabe konzentrieren zu können. Das Ergebnis könnte qualitativ bessere Software sein, die in kürzerer Zeit mit weniger Fehlern entwickelt wird und sowohl Bedürfnisse als auch Anforderungen der Anwender passender abbildet.
Intention statt Implementierung
Der entscheidende Faktor zum Erreichen des Ziels ist, die Intention über die Implementierung zu stellen. Die primäre Fragestellung darf nicht lauten, wie sich Geschäftsprozesse durch Technik abbilden lassen. Stattdessen sind die Absichten und Ziele des Anwenders in den Mittelpunkt zu rücken. Das gestaltet die Anforderungen für die Entwickler greifbarer und verständlicher, da für sie so ein Sinn zu erkennen ist.
Doch nicht nur die Entwicklung könnte von einem fachlich getriebenen Vorgehen profitieren, auch für andere Aspekte würden sich Vorteile ergeben. Dazu zählen beispielsweise das Durchführen von Funktionstests, die fachliche Abnahme und die Verbesserung der Wartbarkeit.
Um das Ziel zu erreichen, gilt es, die für eine Software relevante Fachsprache von vornherein interdisziplinär zu erarbeiten. Dazu bietet sich die Analyse von Geschäftsprozessen an, weil sie die Intention und den Zweck einer Fachdomäne ausdrücken. Das gilt vor allem im Vergleich zu einer Erhebung des rein statischen Datenmodells. Der Kern der Fachsprache besteht daher primär aus Verben, nicht aus Substantiven.
Semantische Ereignisse als Fundament
Jede Fachdomäne lebt davon, dass Ereignisse eintreten und Reaktionen auslösen. Ein Ereignis könnte beispielsweise der Umzug eines Kunden sein, die Reaktion wäre das Einrichten eines Nachsendeauftrags. Um das Beispiel erfolgreich implementieren zu können, sind die Adressdaten zwar erforderlich, für das Verständnis wichtiger ist aber die Intention: Warum haben sich die Adressdaten geändert? Ist der Kunde wirklich umgezogen? Oder wurde nur ein Schreibfehler in den Stammdaten korrigiert? Eventuell wurde auch die Straße umbenannt oder die Postleitzahl neu vergeben?
Die genannten Fälle stellen unterschiedliche Ereignisse dar, auf die entsprechend zu reagieren ist. Daher müssen die Ereignisse semantisch angereichert sein, um die Intention erkennen zu können. Eine Software, die lediglich die Änderung der Adresse feststellt, ist nicht in der Lage, den Situationen in angemessener Form zu begegnen. Daher steht am Beginn einer Entwicklung das gemeinsame Modellieren der Geschäftsprozesse mit semantischen Ereignissen als Fundament. Dabei entstehen Ereignisströme, die sich unter anderem historisch auswerten und analysieren lassen, beispielsweise im Rahmen von Big-Data-Aufgaben und Deep-Learning-Prozessen.