Methode

Gemein­same Sprache

Jede Soft­ware hat das Ziel, Prob­leme inner­halb einer Domäne für ihre Nutzer zu lösen. Im Domain-Driven Design geht es nicht nur um die tech­nische Umsetzung, sondern auch um eine bestimmte Denk­weise beim Ent­wurf eines IT-Systems. Der Ansatz stellt die Model­lierung der Fach­lich­keit und die Schaf­fung einer domänen­spezi­fischen Sprache in den Vorder­grund. Die gemein­same Sprache von Domä­nen­exper­ten und Ent­wick­lern ist ein wich­tiges Ziel von cards+ und dem Domain-Driven Design.

Das Glossar enthält u.a. eine Samm­lung von Fach­begriffen aus dem Geschäfts­feld im Unter­neh­men, in dem das IT-System zum Ein­satz kommt. Es enthält Begriffe, die sehr häu­fig ver­wendet werden oder den Domänen­exper­ten beson­ders wich­tig sind. Es ist ein pro­dukt­spezi­fisches Wör­ter­buch, ein Mini-Lexi­kon, zuge­schnit­ten auf das Pro­dukt. Darum ist es ein sehr wert­voller Teil der Pro­dukt­doku­men­tation über den gesamten Lebens­zyklus der Soft­ware. Ein Ein­trag im Glossar ist in der natür­lichen Sprache der inter­essierten Par­teien (z.B. Nutzer) geschrie­ben. Er enthält Erklärun­gen zum Begriff in der pri­mären Sprache des Ent­wicklungs­projektes. In einem inter­natio­nalen Pro­jekt nutzen Autoren das Glossar auch für die Über­setzung von Begriffen in andere Sprachen.

Wichtig ist, dass Autoren konse­quent Quer­ver­weise als Ver­knüpfung zu Ein­trägen im Glossar ver­wenden. Auf diese Weise ver­schafft der Autor dem Leser einen sehr schnellen Zugriff auf weiter­führende Infor­mationen. Der Autor muss wich­tige Begriffe nicht mehr im Text erläu­tern. Die Texte im Wiki werden sehr kom­pakt. Der Autor ver­meidet mehr­fache Beschrei­bungen eines Begriffes im Text. Damit redu­ziert er auto­matisch die Gefahr wider­sprüch­licher Beschrei­bungen.

Die Bau­steine der System­struktur bilden eine weitere wich­tige Grund­lage für die gemein­same Sprache. Dienste und Objekte bekommen im Wiki durch den Seiten­titel einen ein­deuti­gen Namen. Der Name schlägt eine Brücke zum Code und zu den Test­plänen. Voraus­setzung dafür ist, dass Ent­wickler die Seiten­titel der Bau­steine für die Imple­mentierung ver­wendet, wie fol­gende Bei­spiele zeigen:

  • Der Bau­stein Domain repräsen­tiert eine Gitlab-Gruppe.
  • Der Bau­stein Service ist eine gleich­namige Spring-Boot-Anwen­dung.
  • Der Bau­stein Entity wird durch ein POJO reali­siert.
  • Der Bau­stein Event wird durch ein Avro-Schema spezifi­ziert.
  • Der Bau­stein Case gruppiert Test­fälle eines System­tests.

Autoren brauchen nur den Namen eines Diens­tes oder ein Objek­tes des IT-Systems, um sowohl die Beschrei­bung im Wiki als auch die Imple­men­tie­rung im Code-Reposi­tory zu fin­den. Dieses Praxis stärkt außer­dem die gemein­same Sprache, weil Domä­nen­exper­ten auch Begriffe der Ent­wickler kennen — und umge­kehrt.


Quali­tät

Korrekte Sprache

Eine immer wieder­kehrende spannende Frage ist, ob Ent­wick­ler im Code die Begriffe der Anwen­dungs­domäne ins Englische (ihrer lingua franca) über­setzen sollen — oder eben nicht.

Eine gute Über­setzung erfor­dert ein gewisses Maß an Kennt­nissen der Fremd­sprache. In den fol­genden Bei­spielen wird deut­lich, dass selbst dann eine Über­setzung nicht immer ein­deutig ist. Für die Über­setzung des deut­schen Wortes »Zug­fahrt‘ gibt es zwei Mög­lich­kei­ten. Die erste, »train ride‘, ist die Zug­fahrt eines Reisen­den. Die zweite, »train run‘, ist die betrieb­liche Sicht auf eine Zug­fahrt. Das Eng­lische kennt keine Unter­schei­dung zwischen dem Halt (d.h. der Tat­sache, dass ein Fahr­zeug an einem Ort geplant stehen­bleibt) und der Halte­stelle (d.h. einem Ort, an dem solche Halte statt­fin­den können). Beides heißt »stop‘. Es gibt sogar Begriffe im Deut­schen, für die es keine Über­setzung gibt. »Ver­kehrs­tage­schlüs­sel« kann nicht über­setzt werden. Diese numeri­sche Kodie­rung kennt außer­halb Deutsch­lands kaum jemand.

Entscheidet sich der Pro­dukt­verant­wort­liche und das Team gegen eine pau­schale Über­setzung, dann kann das Glossar als Sperr­liste für nicht über­setz­bare Begriffe ver­wen­det werden. Die Regel ist ein­fach: Kein Begriff aus dem Glossar wird im Code über­setzt. Die Folge dieser Ent­schei­dung ist natür­lich Code in einem Sprachen­mix aus deut­schen Begrif­fen ohne Plu­ral mit eng­lischen Ver­ben (z.B. find) und Stereo­typen (z.B. Reposi­tory).

Sehr vor­teil­haft in diesem Zusam­men­hang ist die Ver­mei­dung der Plural­bil­dung. Ein prak­tische Lösung basiert auf der Ver­wendung des Präfix all in allen Fällen, wo Ent­wick­ler im Code einen Bezeich­ner für eine Menge brauchen.

Bitte hier Klicken, um den Quelltext anzuzeigen
interface ZugfahrtRepository {
    Optional<Zugfahrt> findZugfahrtById(String id);
    List<Zugfahrt> findAllZugfahrt();
}

Ein weiterer Vor­teil dieser Praxis ent­steht bei Wor­ten, deren Plu­ral sich nicht vom Singu­lar unter­schei­det (z.B. das eng­lische Wort »infor­mation« oder das deut­sche Wort »Wasser«) oder bei denen der Plur­al eine andere Bedeu­tung hat (z.B. die deut­schen Worte »Geld« bzw. »Gelder«). Dieser Vor­teil ist sogar unab­hängig von der Sprache im Code.

Es gibt aber Ent­wickler, die sich Code nur in Eng­lisch vor­stellen können. Sie finden deut­sche Klassen­namen unzu­mut­bar, grau­sam, inkor­rekt. Andere Ent­wickler schätzen jedoch die Sicher­heit bei der Ver­wen­dung der Begriffe in ihrer Mutter­sprache, einge­bettet in Code. Das ist les­barer Code, den sie ohne Nach­den­ken oder Wörter­buch sofort ver­ste­hen.

Dieser Kon­flikt kann nur im Team geklärt werden. Ein Pro­dukt­verant­wort­licher muss sich jedoch immer klar machen, dass eine Über­setzung der Begriffe einer nicht eng­lischen Domänen­sprache in eng­lische Begriffe im Code ent­gegen dem Wunsch einer gemein­samen Sprache von Domänen­exprten und Ent­wick­ler ist.