Erste Versionen des Cartoons stammen aus den 1960ern. (Illustrator unbekannt)
Axel Feix
Axel Feix hat langjährige Projekterfahrung als Analyst und Softwarearchitekt. Er unterstützt Kunden als Senior Consultant und Trainer bei der Einführung und Umsetzung von Software-Engineering, Requirements-Engineering, Softwarearchitektur-Management und Architekturdokumentation. Er interessiert sich für was fliegt, alles was man visualisieren und spielen kann, und was die Welt zusammenhält.
Vor vielen Tausend Jahren bestrafte Gott die Menschen in der Stadt Babylon dafür, dass sie sich erdreisteten, einen Turm bis in den Himmel zu bauen. Er sorgte dafür, dass die Menschen sich untereinander nicht mehr verstanden und so musste das Turmbauprojekt eingestellt werden. Seitdem spricht man von der babylonischen Sprachenverwirrung.
Der Turmbau zu Babel als Auslöser der babylonischen Sprachverwirrung
„Ein Redner kann sehr gut informiert sein, aber wenn er sich nicht genau überlegt hat, was er heute diesem Publikum mitteilen will, dann sollte er darauf verzichten, die wertvolle Zeit anderer Leute in Anspruch zu nehmen.“
(Lee Iacocca *1924).
Wenn im IT-Team aneinander vorbeigeredet wird
IT-Teams sind schon ein Volk für sich, und das ist durchaus positiv gemeint. Die ITler bilden oft einen „fachlichen Mikrokosmos“ in einem Unternehmen und bleiben gerne unter sich. Das heißt aber noch lange nicht, dass Entwickler:innen, Softwarearchitekt:innen, Tester:innen, Projektmanager:innen, Scrum Master und Deployment Manager (alle Geschlechter) auch nur ansatzweise eine gemeinsame Sprache sprechen – von Abteilungsleitung, Fachabteilungen und Management einmal ganz abgesehen. Unterschiedliche Ausbildungswege und fachliche Schwerpunkte, aber auch individuelle Unternehmens- und Projekterfahrungen führen in der Regel dazu, dass Fachtermini und Domänenbezeichner nicht durchgängig bekannt sind oder von Mitarbeiter:in zu Mitarbeiter:in anders verstanden werden. Die resultierenden Missverständnisse können gravierende Auswirkungen auf Effizienz und Projekterfolg haben und im Zweifel eine Menge Geld kosten. Was dabei herauskommen kann, sieht man in dem obigen Bild. Aber was tun?
Und die Lösung heißt: Domain-Driven Design (DDD)
Seit Anfang der 2000er-Jahre gibt es mit dem Domain-Driven Design (DDD) eine ganzheitliche Vorgehensweise zur Modellierung komplexer Software. Im DDD geht man dabei von zwei Grundgedanken aus:
- Fachlichkeit und Fachlogik sollten den Schwerpunkt im Softwaredesign bilden
- Ein Modell der Anwendungsdomäne sollte die Grundlage für den Entwurf komplexer Fachlichkeit bilden
Im Domain-driven Design (DDD) führt die Fachlichkeit und nicht die Technik
Die Anwendungsdomäne soll also die Grundlage für den Softwareentwurf bilden. Um diese adäquat zu beschreiben, sollte eine Ubiquitous Language in allen Stufen der Softwareerstellung, d. h. von der Modellierung über die Implementierung bis zum Softwaretest verwendet werden. Objekte und Beziehungen aus den Objekten und Beziehungen im Domänenmodell finden sich also im Sourcecode und Testcode wieder und alle Projektbeteiligten sprechen innerhalb des Projekts dieselbe (Fach-) Sprache. Diese Sprache wird aber nicht einmalig im Domänenmodell entwickelt und dann überall verwendet. Sie wird evolutionär weiterentwickelt und bei Änderungen in der Implementierung hat dies gegebenenfalls auch Auswirkungen auf das Domänenmodell (und alle anderen Artefakte). Damit ist jeder Stakeholder in der Lage, sich in allen Projektartefakten (Modell, Implementierung, Tests, Datenbank etc.) zurechtzufinden und sich an Diskussionen zu beteiligen.
Wenn Sie mehr zu Domain-driven Design (DDD) lernen möchten
Einige Vorzüge einer gemeinsamen Sprache zur Beschreibung des Problemraums und der Anwendungsdomäne haben Sie jetzt kennengelernt. Wenn Ihnen als Softwarearchitekt:in nun noch das nötige Rüstzeug fehlt, um DDD im Umgang mit Stakeholdern und dem Entwicklungsteam einzuführen, empfehlen wir Ihnen unser 3-tägiges Softwarearchitektur-Training ‚Domain Driven Design (DDD)‘. Wenn Sie die Zertifizierung zum Certified Professional for Software Architecture-Advanced Level (CPSA-A ®) anstreben, erhalten Sie mit diesem DDD Training 20 Credit Points im Kompetenzbereich Methodik und 10 Credit Points im Kompetenzbereich Kommunikation.
Was ist Ihre Meinung?
Schon Wilhelm von Humboldt wusste: Die gemeinsame Sprache ist der Schlüssel zur Welt. Wie gehen Sie in Ihren Projekten mit den Fachsprachen der jeweiligen Experten um? Schreiben Sie es uns in die Kommentare. Wir freuen uns auf den Austausch!