Selbstverständlich nimmt kein Entwickler an, er würde den Kunden oder seinen Stellvertreter im Projekt nicht verstehen oder sich nicht verständlich ausdrücken. Trotzdem kommt es in Software-Projekten immer wieder zu Fehlinterpretationen und irreführenden Bezeichnungen. Spätestens nach einigen Jahren im Gebrauch weiß keiner mehr, was mit einem bestimmten Methodennamen genau gemeint war, es kommt zu unsachgemäßer Wiederverwendung und Erweiterungen – die Software erodiert.
Sprachliche Schwierigkeiten in der Entwicklung stabiler Software und Missverständnisse in Anforderungen und Umsetzung werden weder von technikfernen Fachexperten, noch von Code-fixierten Entwicklern verschuldet. Sie sind eine natürliche Herausforderung der Zusammenarbeit.
Der folgerichtige Schritt wäre, ein Glossar anzulegen, um damit die Abkürzungen, Synonyme und kontrovers verwendete Begriffe besser zu verstehen. Wenn nötig, können sogar neue Begriffe erfunden werden, die einen Sachverhalt eindeutig machen oder vereinfachen.
Der Ansatz der ubiquitären Sprache im Domain Driven Design geht noch weiter. Alle an der Erstellung des Systems Beteiligten sollten die festgelegten Ausdrücke aktiv in einer gemeinsamen Sprache etablieren – Fachexperten, Entwickler, Business Analysten, Tester usw. Diese Sprache wird verwendet, um Anforderungen zu diskutieren und zu formulieren, um Testfälle zu erstellen und ja – auch in der Implementierung zur Bezeichnung von Klassen und Services.
Zwei Fragen stellen sich: Woher kommt diese Sprache und wie gelingt die konsequente Verwendung? Außerdem: Was heißt eigentlich „ubiquitär“?
„Ubiquitär“ bedeutet „allumfassend“, oder „überall vorhanden“. Beides ist wichtig: Die Sprache muss alle relevanten Sachverhalte beschreiben und sie muss von allen im Team gesprochen und verstanden werden.
Die ubiquitäre Sprache fällt nicht von Himmel und sie wird auch nicht in Form eines Wörterbuches von der Fachabteilung herausgegeben. Stattdessen entsteht sie durch Diskussionen und Erläuterungen von allen Beteiligten. Im Fokus der ubiquitären Sprache steht das Domänenverständnis. Fachbegriffe und Prozesse werden hinterfragt und ihre Bedeutung genau erklärt und abgegrenzt. Sobald sich alle Beteiligten über die Bedeutung eines Begriffes verständigt haben, wird er ab sofort immer und von allen genau dieser Festlegung entsprechend verwendet. Dabei ist zu beachten, dass ein und derselbe Ausdruck in verschiedenen Kontexten unterschiedliche Bedeutungen haben kann. In diesem Fall darf der Ausdruck nur genutzt werden, wenn klar ist in welchem Kontext dies geschieht.
Die Aufgabe des Entwicklers ist nicht nur zu verstehen, was Fachexperten meinen, sondern auch zu abstrahieren und das Gesamtbild im Blick zu behalten. Zusätzlich bringt er sein eigenes technisches Verständnis ein. Denn auch wenn die Domäne im Fokus steht – umgesetzt werden soll ein IT-System.
Ein Beispiel:
Fachexperte: Für uns arbeiten Berater in Kundenprojekten. Wir möchten ein System erstellen, das unsere Mitarbeiter und Freelancer verwaltet und die Kommunikationswege speichert.
Entwickler: Wir brauchen also eine Datenbank für Mitarbeiter und für Kontaktarten. Kein Problem.
Fachexperte: Nein, die Kontakte werden bei uns im CRM verwaltet. Und insbesondere möchten wir auch die Freelancer im System speichern.
Was ist passiert? Der Entwickler hat sofort Freelancer und Mitarbeiter zu einer Klasse zusammengefasst und diese auch wieder mit Mitarbeiter bezeichnet – ob ein Mitarbeiter nun festangestellt ist oder nicht, ist schließlich nur ein Attribut. Außerdem hat er „Kommunikationswege“ durch „Kontaktarten“ ersetzt. Hätte er seine Überlegungen mit dem Fachexperten besprochen, dann wäre bestimmt herausgekommen, dass ein Kontakt für den Fachexperten ein Kundenkontakt ist und vielleicht würde der Experte einsehen, dass man Freelancer und Festangestellte unter dem Begriff Mitarbeiter sammeln kann. Vermutlich würde es sogar eine Diskussion darüber geben, wie groß die Unterschiede zwischen Freelancern und Festangestellten sind und ob sie wirklich in eine gemeinsame Klasse gehören.
Nehmen wir an, die Etablierung einer ubiquitären Sprache gelingt gut. Die Begriffe und festgestellten Zusammenhänge sind in einem Domänenmodell gut dokumentiert. Was für Auswirkungen hat das auf die Entwicklung? Wo ist der Unterschied zu einem reinen Glossar?
Zunächst einmal verschieben sich viele Entscheidungen auf einen früheren Zeitpunkt im Entwicklungsprozess, weil sie durch fachliche Argumente getroffen werden müssen. Im Beispiel von oben wäre es möglich, dass Freelancer und Festangestellte nichts miteinander zu tun haben, außer dass beide (genau wie Kunden) über Kommunikationswege erreicht werden können. Die Frage, ob sie beide von derselben Klasse erben, sollte dann aus fachlicher Perspektive diskutiert werden. Für Festangestellte macht es zum Beispiel keinen Sinn, umfangreiche Informationen über Verträge, Stundensätze und Beschäftigungszeiträume zu hinterlegen. Umgekehrt braucht ein Freelancer keine Urlaubsverwaltung. Ob die Unterschiede gravierend genug sind, in verschiedenen Kontexten implementiert zu werden, sollte keine technische Entscheidung sein.
Zum anderen ist die Sprache des Modells die Basis für die Implementierung. Sie verwendet dieselben Begriffe wie das Modell und umfasst genau die dort beschriebenen Operationen. Wird während der Umsetzung festgestellt, dass die Formulierung ungünstig ist, so wird auch das Modell geändert. Das Modell spiegelt also zu jedem Zeitpunkt die Implementierung und umgekehrt.
Was ist der Vorteil der konsequenten Verwendung der ubiquitären Sprache?
Missverständnisse werden vermieden, auch bei komplexen Systemen und insbesondere bei Änderungen und spät geäußerten Anforderungen. Die Art der Umsetzung von fachlichen Entscheidungen wird nicht mehr alleine von Entwicklern getroffen und Probleme kommen früher ans Licht, nämlich schon bei der Modellerstellung. Die Domäne rückt ins Zentrum der Entwicklung und garantiert die Stabilität des Systems über wechselnde Entwicklerteams, Umsetzungsparadigmen und technische Infrastruktur hinaus.
