"Ich öffne die Büchse der Pandora" – Interview mit Alberto Brandolini
Alberto Brandolini ist der Erfinder des EventStorming – einem Workshop-Format im Kontext von Domain-driven Design, mit dem man schnell herausfinden kann, was in der Domäne einer Software passiert.
- Björn Bohn
Alberto Brandolini ist Erfinder der EventStorming-Methode – einem Konzept, das die Thesen hinter Domain-driven Design (DDD) in die Praxis übersetzt. Sein Buch "Introducing EventStorming – An act of deliberate collective learning" fasst seine wesentlichen Erkenntnisse zusammen. Tobias Goeschel, Principal Consultant und Trainer beim IT-Beratungshaus codecentric, hat ihn für heise Developer zu den Hintergründen gefragt.
heise Developer: Im Buch "Domain-driven Design" (2004) stellt Eric Evans einen Ansatz vor, komplexe Softwaresysteme aus einem Geschäftsfeld heraus zu entwerfen, angefangen bei einem Domänenmodell, das eine Zusammenarbeit von Domänenexperten und Softwareentwicklern erfordert. Dazu stellt er ein Framework für Designentscheidungen sowie die entsprechende Terminologie für die Diskussion über das Design der Anwendungsdomänen zur Verfügung. Kannst du kurz erklären, warum ein gemeinsames Verständnis von der Anwendungsdomäne in unserer Branche wichtig ist?
Alberto Brandolini: Domain-driven Design zeigt einen grundlegenden Fehler in der Softwareentwicklung für Unternehmen auf: die Annahme, dass wir Software auf der Grundlage verlässlicher Anforderungen bauen können. "Bauen" ist übrigens ein furchtbares Wort, denn Software ist kein Haus.
Das ist eine Illusion, und eine gefährliche noch dazu. Gewissheit besteht zwar bei einzelnen Anforderungen wie: "Es sollte möglich sein, Dateien aus der Version 2.1 zu importieren". Aber viele Anforderungen sind nicht unumstößlich. Sie enthalten Widersprüche – das liegt in der Natur von Organisationen mit Silos und Abteilungen, in denen unterschiedliche Ansichten und Bedürfnisse herrschen, ganz zu schweigen von versteckten individuellen Zielen. Evans verlagert außerdem den Fokus auf die Sprache. Selbst ihr kann man nicht trauen: Begriffe sind nicht eindeutig.
Deshalb macht sich DDD dafür stark, Software auf eine Art und Weise zu entwickeln, die ein hohes Maß an Geschick und Kompetenz in Softwarearchitektur voraussetzt. Dadurch hat man mehrere Optionen zur Verfügung. Außerdem sollte es möglich sein, mehrere, jeweils sehr effiziente Modelle zu entwickeln, die jeweils perfekt auf die lokalen Gegebenheiten zugeschnitten sind.
"Der unsichtbare Feind ist die Vorstellung vom "großen datenzentrischen Modell", die in den letzten Jahren so weit verbreitet war. Die grundlegende Mehrdeutigkeit von Sprache wurde durch eine datenzentrierte Implementierung beseitigt, die ganze Unternehmen zwang, sich darauf zu einigen, was "Kunde" oder "Bestellung" bedeutet und wie der Datenaustausch erfolgen soll – nur um sich einige Jahre später in einer Sackgasse wiederzufinden: Jeder ist auf dieselben Daten angewiesen, sodass jede Änderung zu riskant ist. Das Vertrauen geht verloren, die Weiterentwicklung verlangsamt sich und die Arbeitsplätze verlieren an Attraktivität.
heise Developer: Das sind aber keine neuen Herausforderungen, oder?
Brandolini: Ich glaube, das ganze Problem existiert schon sehr lange, aber es fliegt uns erst jetzt um die Ohren. Zwei Faktoren sind dafür verantwortlich. Zum einen Microservices: Sie sind momentan angesagt, aber ihr Versprechen kann nur mit einer DDD-Denkweise erfüllt werden, besonders, wenn es um Bounded Contexts geht. Zum anderen der Arbeitsmarkt: Entwickler tendieren immer mehr dazu, ungesunde Arbeitsumgebungen zu verlassen, und meiner Meinung nach gibt es eine starke Korrelation zwischen bestimmten Architekturen, bei denen die Angst, etwas kaputtzumachen, vorherrscht, und der Unfähigkeit, Talente zu halten.
Ein tiefes Verständnis der Fachdomäne – wofür Domain-driven Design ja eintritt – kann die treibende Kraft für einen zielgerichteteren Ansatz in der Softwareentwicklung sein. Dabei sollte man verstehen, was richtig ist, und daraus die Software schaffen, die mit den wenigsten Kompromissen einhergeht. Das fühlt sich nicht nur gut an, sondern bringt mich auch dazu, im Unternehmen bleiben zu wollen, damit ich sehe, was am Ende dabei herauskommt.
