Hauptgedanke

Eine Ausnahme namens ElementAnnuléNonModifiable ist keine Fehlermeldung: Sie ist eine fachliche Regel, in Code geschrieben, lesbar auch für jemanden im Support, der nicht programmiert. Eine Ausnahme namens InvalidStateException sagt dem Prozessor dasselbe und sonst niemandem etwas. Dieser Unterschied, nicht die technische Qualität des Repositorys, entscheidet darüber, ob eine Produktfrage dort ihre Antwort finden kann.

Die Bedingung gilt für das gesamte Material: Entitäten, die die Namen tragen, die die Nutzer verwenden, Aktionen, deren Bezeichnung sich lesen lässt, Ereignisse, die erzählen, was geschehen ist, Policies, die die Kettenreaktionen sichtbar machen, Module mit vorhersehbarer Struktur. Ein Repository, in dem sich die Begriffe der Domäne hinter technischen Namen verstecken und die Regeln verstreut liegen, bleibt undurchsichtig, wie sorgfältig es auch geschnitten oder mit Tests abgedeckt sein mag.

Die Anforderung ist alt — Ansätze des domänengetriebenen Entwurfs verfolgen sie seit Langem —, und sie ist nicht mit den Assistenten entstanden. Ein Entwickler, der ein solches Repository übernimmt, zahlt denselben Preis einer ständigen Übersetzung zwischen dem fachlichen Bedarf und der Mechanik der Software; jede Weiterentwicklung verlangt, diese Verbindung neu herzustellen, jede Suche nach einer Regel wird teurer. Was die Möglichkeit, den Code zu befragen, ändert: Dieser Mangel wird von außerhalb des technischen Teams messbar. Er äußert sich nicht mehr in diffuser Langsamkeit, sondern in Antworten, die niemand bekommen kann.

Warum das wichtig ist

Das verschiebt das Kriterium, das man anlegt, bevor man ein System zum Befragen einrichtet. Die Frage an ein Repository lautet nicht „Ist es gut gepflegt?“, sondern „Steht das Vokabular der Domäne darin?“ — zwei Eigenschaften, die oft zusammen auftreten, aber nicht zwingend zusammenhängen.

Es liefert auch ein nichttechnisches Argument für eine Investition, die bisher nur ein technisches hatte. Begriffe in die Sprache des Fachbereichs umzubenennen ist keine Vorliebe von Handwerkern mehr, sobald Support, Vorvertrieb und Product Management davon abhängen, Antworten zu bekommen.

Nuancen und Grenzen

Einheitlichkeit gibt es nicht: Dasselbe Repository spricht im Abrechnungsmodul, das vor zwanzig Jahren von Leuten mit Domänenwissen geschrieben wurde, die Fachsprache und bleibt in der Integrationsschicht stumm. Die Bedingung prüft man Zone für Zone, nicht für das ganze Repository.

Das im Code eingeschriebene Vokabular ist außerdem zeitgebunden. Ein Entitätsname, der drei Neupositionierungen überlebt hat, erzählt von einem Geschäft, das man nicht mehr betreibt, und gerade seine Lesbarkeit macht ihn irreführend.

Schließlich kann ein zutreffender fachlicher Name eine falsche Regel verdecken. Dass eine Ausnahme eine Regel ausdrückt, macht diese lesbar, nicht richtig: Befragbar wird der Code, nicht das gewollte Produkt.

Offene Fragen

• Wer entscheidet über das Vokabular, wenn die Nutzer ein Objekt anders nennen als der Code und beide Sprachgebräuche im Unternehmen ihre Fürsprecher haben?
• Woran misst man, bevor man die Arbeit aufnimmt, den Abstand zwischen dem Vokabular eines Repositorys und dem der Domäne?