© Excellent backgrounds/Shutterstock.com
Java Magazin
DDD-Serie, Teil 3: Ubiquitous Language

Warum ist Sprache so wichtig?

Ein Element, das in der gesamten Domain-driven-Design-Literatur querschnittlich präsent ist, ist die Ubiquitous Language, die allgegenwärtige Sprache. Allgegenwärtig bezieht sich darauf, dass es sich hierbei um eine Sprache handelt, die von Softwareentwickler*innen und Fachexpert*innen gemeinsam gesprochen wird. Diese Sprache soll dann auch die Basis für die Entwicklung des Softwaremodells sein. Im Rahmen dieses Artikels gehen wir erst auf die Motivation für die Etablierung einer Ubiquitous Language ein, bevor schließlich das Potenzial und die Möglichkeiten für die Arbeit mit einer solchen Sprache vorgestellt werden. Weiterhin werden noch kurz die Vorgehensweisen zur Herleitung einer Ubiquitous Language erläutert.

Michael Plöd


Immer wieder wird betont, dass eine direkte Kollaboration zwischen Fachexpert*innen und Entwickler*innen von zentraler Bedeutung ist. Insbesondere die zwei Klassiker der Domain-driven Design-Literatur von Eric Evans [1] und Vaughn Vernon [2] stellen eine solche direkte Kollaboration in den Mittelpunkt der projekt-kulturellen Aspekte der Methode. Allerdings zeigt sich in der Praxis häufig, dass eine direkte Zusammenarbeit nicht ganz einfach ist, da mit unterschiedlichen Sprachen gearbeitet wird. Die Entwicklungsteams arbeiten mit und sprechen in sehr technischen, meist englischen Begriffen. Andererseits ist auf Fachseite häufig zu beobachten, dass hier in einer fachlichen Sprache gesprochen wird. Je nach Organisation stammt diese entweder aus dem englischen oder aus dem deutschen Vokabular. Exemplarisch könnte man etwas überspitzt anführen, dass Entwicklungsteams einen Gegenstand, den ein Fachteam beispielsweise „Trolley“ nennt, in der Implementierung als „RollableStuffContainer“ umsetzt. Um solche Differenzen besser zu adressieren, haben viele – meist größere – Organisationen Requirements-Engineering-Teams etabliert, die einerseits Anforderungen aufnehmen, klären und priorisieren sollen. Andererseits befinden sich diese Teams genau an der Schnittstelle zwischen IT und Fachbereich, weshalb sie natürlich auch auf sprachlicher Ebene Übersetzungsarbeit zwischen IT- und Fachsprache leisten. Mit einer solchen Lösung gehen allerdings häufig Reibungsverluste einher, die dazu führen, dass sich fachliche Fehler in die Software einschleichen.

ArtikelserieTeil 1: Warum Domain-driven Design?Teil 2: Strategic DesignTeil 3: Ubiquituous LanguageTeil 4: Taktisches DesignTeil 5: DDD und Microservices

Deshalb setzt Domain-driven Design auf eine Ubiquitous Language. Dabei handelt es sich um ein Vokabular, das sich Domain Experts und Entwickler*innen teilen. Die allgegenwärtige Sprache ist somit eine geteilte Sprache zwischen Fachbereich und IT. Eine solche Sprache entsteht selbstredend nicht von selbst oder per Anordnung von oben, sie muss iterativ und kollaborativ erarbeitet werden.

Herleitung einer Ubiquitous Language

In der Vergangenheit wurde im Rahmen der Analyse oftmals sehr schnell mit technisch geprägten Werkzeugen, beispielsweise mit UML-Tools, gearbeitet. Diese Programme funktionieren für technikaffine Projektmitarbeiter*innen zwar meist sehr gut, allerdings exkludieren sie eher fachlich orientierte Teammitglieder und verleiten die Teilnehmer*innen eines Analyseworks...

Java Magazin
DDD-Serie, Teil 3: Ubiquitous Language

Warum ist Sprache so wichtig?

Ein Element, das in der gesamten Domain-driven-Design-Literatur querschnittlich präsent ist, ist die Ubiquitous Language, die allgegenwärtige Sprache. Allgegenwärtig bezieht sich darauf, dass es sich hierbei um eine Sprache handelt, die von Softwareentwickler*innen und Fachexpert*innen gemeinsam gesprochen wird. Diese Sprache soll dann auch die Basis für die Entwicklung des Softwaremodells sein. Im Rahmen dieses Artikels gehen wir erst auf die Motivation für die Etablierung einer Ubiquitous Language ein, bevor schließlich das Potenzial und die Möglichkeiten für die Arbeit mit einer solchen Sprache vorgestellt werden. Weiterhin werden noch kurz die Vorgehensweisen zur Herleitung einer Ubiquitous Language erläutert.

Michael Plöd


Immer wieder wird betont, dass eine direkte Kollaboration zwischen Fachexpert*innen und Entwickler*innen von zentraler Bedeutung ist. Insbesondere die zwei Klassiker der Domain-driven Design-Literatur von Eric Evans [1] und Vaughn Vernon [2] stellen eine solche direkte Kollaboration in den Mittelpunkt der projekt-kulturellen Aspekte der Methode. Allerdings zeigt sich in der Praxis häufig, dass eine direkte Zusammenarbeit nicht ganz einfach ist, da mit unterschiedlichen Sprachen gearbeitet wird. Die Entwicklungsteams arbeiten mit und sprechen in sehr technischen, meist englischen Begriffen. Andererseits ist auf Fachseite häufig zu beobachten, dass hier in einer fachlichen Sprache gesprochen wird. Je nach Organisation stammt diese entweder aus dem englischen oder aus dem deutschen Vokabular. Exemplarisch könnte man etwas überspitzt anführen, dass Entwicklungsteams einen Gegenstand, den ein Fachteam beispielsweise „Trolley“ nennt, in der Implementierung als „RollableStuffContainer“ umsetzt. Um solche Differenzen besser zu adressieren, haben viele – meist größere – Organisationen Requirements-Engineering-Teams etabliert, die einerseits Anforderungen aufnehmen, klären und priorisieren sollen. Andererseits befinden sich diese Teams genau an der Schnittstelle zwischen IT und Fachbereich, weshalb sie natürlich auch auf sprachlicher Ebene Übersetzungsarbeit zwischen IT- und Fachsprache leisten. Mit einer solchen Lösung gehen allerdings häufig Reibungsverluste einher, die dazu führen, dass sich fachliche Fehler in die Software einschleichen.

ArtikelserieTeil 1: Warum Domain-driven Design?Teil 2: Strategic DesignTeil 3: Ubiquituous LanguageTeil 4: Taktisches DesignTeil 5: DDD und Microservices

Deshalb setzt Domain-driven Design auf eine Ubiquitous Language. Dabei handelt es sich um ein Vokabular, das sich Domain Experts und Entwickler*innen teilen. Die allgegenwärtige Sprache ist somit eine geteilte Sprache zwischen Fachbereich und IT. Eine solche Sprache entsteht selbstredend nicht von selbst oder per Anordnung von oben, sie muss iterativ und kollaborativ erarbeitet werden.

Herleitung einer Ubiquitous Language

In der Vergangenheit wurde im Rahmen der Analyse oftmals sehr schnell mit technisch geprägten Werkzeugen, beispielsweise mit UML-Tools, gearbeitet. Diese Programme funktionieren für technikaffine Projektmitarbeiter*innen zwar meist sehr gut, allerdings exkludieren sie eher fachlich orientierte Teammitglieder und verleiten die Teilnehmer*innen eines Analyseworks...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang