Software fachlich modellieren: CRUD war gestern | heise online
<html> <div class=„article-layoutheader-container“> <header class=„ a-article-header “><h1 class=„ a-article-headertitle “ dir=„ltr“>Software fachlich modellieren: CRUD war gestern </h1> <p class=„a-article-headerlead“ dir=„ltr“> Wer Software entwickelt, muss die zugrunde liegende Fachlichkeit verstehen. Dabei hilft eine geeignete Modellierung der Fachdomäne. </p> <a-lightbox class=„article-image“ tabindex=„1“ src=„/imgs/18/4/8/0/6/5/2/3/shutterstock_1061212223-db24247d1b405449.jpeg“ modal-id=„a-8421“><figure><div class=„article-imagegallery-container“> <img src=„https://heise.cloudimg.io/width/610/q85.png-lossy-85.webp-lossy-85.foil1/_www-heise-de_/imgs/18/4/8/0/6/5/2/3/shutterstock_1061212223-db24247d1b405449.jpeg“ srcset=„https://heise.cloudimg.io/width/336/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/4/8/0/6/5/2/3/shutterstock_1061212223-db24247d1b405449.jpeg 336w, https://heise.cloudimg.io/width/1008/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/4/8/0/6/5/2/3/shutterstock_1061212223-db24247d1b405449.jpeg 1008w, https://heise.cloudimg.io/width/610/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/4/8/0/6/5/2/3/shutterstock_1061212223-db24247d1b405449.jpeg 610w, https://heise.cloudimg.io/width/1220/q70.png-lossy-70.webp-lossy-70.foil1/_www-heise-de_/imgs/18/4/8/0/6/5/2/3/shutterstock_1061212223-db24247d1b405449.jpeg 1220w “ sizes=„(max-width: 991px) 95vw,610px“ alt=„“ width=„610“ height=„342“ class=„legacy-img“ referrerpolicy=„no-referrer“ /></div> <figcaption class=„a-caption“> (Bild: tomertu/Shutterstock.com) </figcaption></figure><section class=„heise-modal“><div class=„stage“></div></section></a-lightbox><div class=„a-article-headerpublish-info“> <div class=„a-publish-info“> <div class=„a-publish-inforead-time“> Lesezeit: 20 Min. </div> <div class=„a-publish-infobranding“> <a href=„https://www.heise.de/developer/“> <div class=„a-article-branding a-article-branding–with-hover“ title=„Ein Beitrag von: Developer“> Developer </div> </a> </div> </div> <div class=„creator“> Von <ul class=„creatornames“><li class=„creatorname“>Golo Roden</li> </ul></div> </div></header><aside class=„article-layoutheader-wrbng“><div> <div id=„HEI_D_Incontent-1-label“ class=„ad-label“>Anzeige</div> <div id=„HEI_D_Incontent-1“ data-size=„300×250,300×600,300×3,fluid“ class=„ad ad–sticky“> </div> </div></aside></div><div class=„article-layoutcontent-container“> <div class=„article-layoutcontent“ dir=„ltr“> <div class=„article-content js-upscore-article-content-for-paywall“> <p>75 Prozent aller Softwareprojekte scheitern! Dazu habe ich im vergangenen Oktober bereits <a href=„https://www.heise.de/blog/75-Prozent-aller-Softwareprojekt-scheitern-was-tun-9979648.html“>einen Beitrag geschrieben</a>. Darin habe ich auch ein essenzielles und grundlegendes Problem angesprochen: Viele Softwareprojekte scheitern nämlich nicht an der Technik, sondern viel eher an einem fehlenden Verständnis der zugrunde liegenden Fachlichkeit. Denn es kommt äußerst selten vor, dass Entwicklerinnen und Entwickler sowie Fachexpertinnen und Fachexperten die gleiche Sprache sprechen. Allerdings ist damit nicht eine natürliche Sprache wie Deutsch, Englisch oder Französisch gemeint, sondern vielmehr das Fehlen einer gemeinsamen Fachsprache (und letztlich eines gemeinsamen Verständnisses, worum es bei der zu entwickelnden Software inhaltlich überhaupt geht).</p> <div class=„ad-label“ id=„HEI_M_Incontent-1-label“>Anzeige</div> <a-paternoster class=„a-paternoster-ad“ height=„360“ media=„(min-width: 320px) and (max-width: 767px)“><div class=„a-paternoster-clip“><div class=„a-paternoster-centered a-paternoster-container“><div> <div class=„“ id=„HEI_M_Incontent-1“> </div></div></div></div></a-paternoster><p>Dass dies zu impliziten Annahmen, zu Missverständnissen und zu fehlerhaften Interpretationen führt, haben wir in dem erwähnten Video ausführlich erläutert. Das bedeutet letztlich nichts anderes, als dass Entwicklerinnen und Entwickler eine Software immer so bauen, wie <em>sie</em> diese verstehen – und nicht unbedingt so, wie das Business die Software benötigt. Folglich stellt sich die Frage, was man dagegen unternehmen kann: Eine mögliche Antwort ist eine wirklich gute Modellierung der Fachlichkeit. Wie eine solche Modellierung entwickelt wird, das erläutere ich Ihnen heute in diesem Blogpost.</p><h3 class=„subheading“ id=„nav_sprache_als0“>Sprache als Ursache des Problems</h3><p>Als allererstes sollte man zunächst verstehen, wo das Problem der fehlenden gemeinsamen Sprache und des fehlenden gemeinsamen Verständnisses überhaupt herkommt. Denn eigentlich sollte man meinen, dass es nicht so übermäßig schwierig sein kann, miteinander zu sprechen. Das Problem ist jedoch, dass hier unterschiedliche Welten aufeinandertreffen, die beide nie gelernt haben, mit der jeweils anderen Disziplin zu kommunizieren:</p><ul class=„rtelist rtelist–unordered“><li>Fachexpertinnen und Fachexperten sind die sehr technologieorientierte Sprache aus der Entwicklung nicht gewohnt und verstehen sie daher nicht.</li><li>Entwicklerinnen und Entwickler wiederum sind die Fachsprache nicht gewohnt und begreifen sie deshalb ebenfalls nicht, zumal sie die dahinterliegenden Geschäftsprozesse in der Regel nicht im Detail kennen.</li></ul><p>Das Problem lautet jedoch: Wie entwickeln Sie eine Software, die ein fachliches Problem lösen soll, wenn das fachliche Problem gar nicht verstanden wurde? Ganz einfach: Das funktioniert nicht.</p><h3 class=„subheading“ id=„nav_programmiersprac1“>Programmiersprache X oder Framework Y?</h3> <div class=„ad-mobile-group-1“> <div class=„ad-label“ id=„HEI_M_Incontent-3-label“>Anzeige</div> <div class=„ad ad–sticky“ id=„HEI_M_Incontent-3“> </div><p>Das Erschreckende ist jedoch, dass zu viele Teams und Unternehmen dies einfach ignorieren oder, was ich persönlich noch viel schlimmer finde, dass ihnen diese Diskrepanz nicht einmal bewusst ist. Da wird dann wochen- oder monatelang diskutiert, ob man Programmiersprache X oder doch lieber Framework Y einsetzen sollte, aber niemand kommt auf den Gedanken, sich einmal gezielt mit der Fachlichkeit auseinanderzusetzen.</p> <p>Dann wird irgendwann drauflos entwickelt, und das geht ein paar Monate oder vielleicht auch ein oder zwei Jahre gut, aber schließlich erkennt man über kurz oder lang, dass die Software nicht genau das tut, was ursprünglich einmal gewünscht war. Und dann muss nachgebessert werden: Alles dauert auf einmal länger, alles wird teurer, und selbstverständlich ist das Fundament (weil falsche Annahmen getroffen wurden) in eine völlig unpassende Richtung entwickelt worden, sodass die Anpassungen jetzt nur sehr umständlich und damit auch wieder äußerst kostspielig möglich sind.</p><p>Mit hoher Wahrscheinlichkeit kommt dann jemand um die Ecke und behauptet:</p><p class=„indent rteabs–indent“><em>„Ich hab’s Euch ja von vornherein gesagt: Hätten wir nicht auf Technologie X, sondern auf Technologie Y gesetzt, dann hätten wir das Problem jetzt nicht!“</em></p><p>Der Punkt ist jedoch: Das Problem wäre genauso vorhanden, nur auf einer anderen technologischen Basis. Denn das ist der springende Punkt: In den seltensten Fällen ist die Technologie an sich das Problem (womit ich nicht sagen möchte, dass es nicht bessere und schlechtere Technologieentscheidungen gäbe, in der Regel wird nur der Einfluss der Technologiewahl auf den Erfolg eines Projekts massiv überschätzt).</p><h3 class=„subheading“ id=„nav_crud_als2“>CRUD als Ausgangsbasis</h3><p>Das bedeutet: Wenn Sie sicherstellen möchten, dass Sie eine zum zugrunde liegenden fachlichen Problem passende Software entwickeln, und das sogar noch zielgerichtet, funktioniert es letztlich nur, wenn Sie von Anfang an verstehen, worum es aus fachlicher Sicht überhaupt geht. Das mag trivial erscheinen – die Praxis sieht leider allzu oft anders aus.</p><p>Oft steht uns Entwicklerinnen und Entwicklern nämlich etwas im Weg, das wir leider von klein auf beigebracht bekommen haben: Das Denken in Datenbanktabellen. Wir alle haben in unserer Ausbildung oder in unserem Studium gelernt, Daten in relationalen Strukturen abzulegen. Um mit diesen Strukturen zu arbeiten, kennen wir vier Verben, nämlich <em>Create</em>, <em>Read</em>, <em>Update</em> und <em>Delete</em>, häufig abgekürzt als <em>CRUD</em>. Wir haben gelernt, dass wir damit de facto alles modellieren können, und aus technischer Sicht ist das auch durchaus korrekt.</p><h3 class=„subheading“ id=„nav_doch_was_ist3“>Doch was ist mit der Fachsprache?</h3><p>Aber das ändert selbstverständlich nichts daran, dass es sich bei diesen Wörtern um die Fachsprache der Datenbank handelt. <em>Create</em>, <em>Read</em>, <em>Update</em> und <em>Delete</em> sind nämlich rein technische Begriffe, die von Datenbanken genutzt werden. Da wir häufig mit Code zu tun haben, der auf Datenbanken zugreift, sind wir dazu übergegangen, diese vier Verben auch in unserem Code zu verwenden: So entstehen dann Funktionen mit Namen wie beispielsweise <code>UpdateBook</code>.</p><p>Aus technischer Sicht mag das sogar durchaus passend sein, wenn diese Funktion den Datensatz für ein Buch in der Datenbank aktualisiert. Das Problem besteht jedoch darin, dass dies nicht den <em>fachlichen</em> Use Case widerspiegelt. Denn <em>warum</em> wird das Buch beziehungsweise dessen Datensatz aktualisiert? Diese Information liefert der Funktionsname leider nicht. Das Problem ist außerdem, dass sich hinter diesem <em>Update</em> alles Mögliche verbergen kann. Ich bin mir sicher, dass wenn Sie an dieser Stelle kurz innehalten und sich überlegen, wie viele Gründe Ihnen spontan einfallen, warum man ein Buch aktualisieren können sollte, Sie keine Schwierigkeit haben, rasch auf zehn oder zwanzig unterschiedliche Gründe zu kommen.</p><p>Ich bin mir außerdem sicher, dass Sie – je nachdem, für welche Fachlichkeit Sie sich entscheiden – die Anwendung durchaus unterschiedlich entwickeln würden: Ein System zum Verwalten der ausgeliehenen Bücher in einer Bibliothek unterscheidet sich klar von einem System für einen großen Onlineshop, und beide sind wiederum etwas ganz anderes als ein System, das Autorinnen und Autoren beim Schreiben von Romanen unterstützen soll.</p><p>In allen drei Fällen kann es notwendig sein, ein Buch früher oder später zu aktualisieren, doch der gesamte Workflow darum ist jeweils ein völlig anderer, und abhängig davon würden vermutlich einige Dinge auch unterschiedlich gehandhabt. Ohne vertiefte Kenntnisse des umgebenden Prozesses ist es daher schwierig, Code zu schreiben, der das Richtige tut, und es greift zu kurz, einfach nur <code>UpdateBook</code> umzusetzen.</p><h3 class=„subheading“ id=„nav_crud_ist_ein4“>CRUD ist ein Antipattern</h3><p>Langer Rede, kurzer Sinn: Wenn wir ohne die Prozesse zu kennen den Code für die Anwendung nicht adäquat und zielgerichtet schreiben können, sollten wir dann nicht vielleicht versuchen, diese Prozesse zunächst besser zu verstehen? Zu verstehen, worum es bei der gesamten Thematik überhaupt geht? Wer etwas macht? Was diese Person macht? Warum sie das macht? Wann und wie oft sie es macht? Welchen Zweck das Ganze hat? Welche Konsequenzen es nach sich zieht? Und so weiter.</p><p>Falls Sie jetzt denken:</p><p class=„indent rteabs–indent“><em>„Stimmt, das wäre sinnvoll!“</em></p><p>Dann müssten wir als Nächstes überlegen, wie man Prozesse angemessen beschreiben kann. Eines kann ich Ihnen schon vorab verraten: Die Begriffe <em>Create</em>, <em>Read</em>, <em>Update</em> und <em>Delete</em> sind dabei ziemlich fehl am Platz. Tatsächlich ist die Denkweise in diesen vier Verben <a href=„https://www.youtube.com/watch?v=MoWynuslbBY“ rel=„external noopener“ target=„_blank“>sogar ein Antipattern</a>.</p><p>Doch wenn wir CRUD nicht verwenden können, um fachliche Prozesse zu beschreiben, was machen wir dann stattdessen? Benötigt wird dafür eine Methode, um Geschäftsprozesse als das darzustellen, was sie wirklich sind – nämlich eine Abfolge von Ereignissen. Stellen Sie sich vor, Sie kommen abends nach Hause und Ihre Partnerin oder Ihr Partner fragt, wie Ihr Tag war, woraufhin Sie erzählen, dass zuerst dieses und dann jenes geschehen sei. Sie berichten von Ereignissen, die Sie im Laufe des Tages erlebt haben – und genau das geschieht auch in einem Geschäftsprozess.</p><h3 class=„subheading“ id=„nav_eine5“>Eine Stadtbibliothek</h3><p>Nehmen wir als Beispiel die vorhin bereits kurz erwähnte Bibliothek. Wir können überlegen, welche Prozesse dort überhaupt auftreten: Welche Aktionen finden aus fachlicher Sicht in einer Bibliothek statt?</p><p>Man erkennt rasch, dass einer der wichtigsten Vorgänge darin besteht, dorthin zu gehen, um ein Buch zu leihen. Geliehene Bücher müssen über kurz oder lang natürlich auch wieder zurückgegeben werden, doch die Ausleihe kann verlängert werden, sofern niemand anderes das Buch vorbestellt hat. Wer zu spät mit der Rückgabe ist, muss möglicherweise eine Strafe zahlen, und die Bibliothek nimmt regelmäßig neue Bücher in den Bestand auf und entfernt alte, die nicht mehr in gutem Zustand sind.</p><p>Hier bemerken Sie bereits, wie reichhaltig die Sprache an dieser Stelle ist und wie viele Verben wir dabei verwenden: <em>Ausleihen</em>, <em>zurückgeben</em>, <em>verlängern</em>, <em>vorbestellen</em>, <em>bezahlen</em>, <em>aufnehmen</em>, <em>entfernen</em> und so weiter.</p><h3 class=„subheading“ id=„nav_fachlichkeit_im6“>Fachlichkeit im Code abbilden</h3><p>Vielleicht denken Sie jetzt, es sei doch logisch, auf diese Weise darüber zu sprechen, und im Grunde stimmt das auch. Doch warum findet man dann im Code höchstwahrscheinlich nur eine technisch benannte Funktion (nämlich <code>UpdateBook</code>) und nicht fachlich benannte Funktionen, etwa <code>BorrowBook</code>, <code>RenewBook</code> und <code>ReturnBook</code>?</p><p>Das ist eine berechtigte Frage, denn hätten wir diese Funktionen, könnten sie intern selbstverständlich immer noch ein <em>Update</em> oder eine andere Datenbankoperation ausführen, doch unser Code würde plötzlich eine fachliche Geschichte erzählen. Es wäre sehr viel einfacher, im Gespräch mit einer Fachexpertin oder einem Fachexperten nachzuvollziehen, was gemeint ist, weil sich die verwendeten Begriffe auch im Code wiederfinden würden.</p><p>Und das möglicherweise nicht nur im Code, sondern sogar auch in der API und in der UI. Wie viel besser könnte ein System gestaltet sein, wenn es auf diesen Begriffen basieren würde, anstatt stets nur von <code>UpdateBook</code> zu sprechen? Wie viel besser könnte eine UI sein? Wie viel effektiver könnte man Anwenderinnen und Anwender in ihrer Intention abholen und unterstützen?</p><h3 class=„subheading“ id=„nav_die_realität7“>Die Realität kennt keine Updates</h3><p>An dieser Stelle kommen wir zum entscheidenden Punkt: Wenn wir zu der Erkenntnis gelangen, dass es besser ist, in unserem Code, in der API, in der UI und auch überall sonst mit fachlichen Begriffen zu arbeiten, anstatt mit technischen, warum modellieren wir dann nicht einfach die fachlichen Ereignisse so, wie sie wirklich stattfinden?</p><p>Was in der Realität geschieht, sind nämlich keine <em>Updates</em>, sondern Ereignisse, die wir in der Software nachbilden möchten. Genau aus diesem Grund sollten wir nicht nur in fachlichen Funktionen denken, sondern auch in fachlichen Events. Wenn wir unsere Software so gestalten, dass sie von echten Events angetrieben wird, verfügen wir nämlich plötzlich über eine Architektur und eine Codebasis, die die Realität widerspiegeln, anstatt nur ein unzureichendes technisches Abbild zu sein, das eine sprachliche Kluft und viel Raum für Missverständnisse und Interpretationen hinterlässt.</p><p>Genau an dieser Stelle setzt die Event-Modellierung an. Wenn wir akzeptieren, dass unsere Software die fachliche Realität widerspiegeln sollte und dass Events dafür das Mittel der Wahl sind, müssen wir uns zwangsläufig fragen: Wie finden wir die richtigen Events? Welche Ereignisse sind tatsächlich relevant? Welche beschreiben eine Veränderung? Auf welche Weise schneide ich meine Events so, dass sie fachlich sinnvoll sind?</p><p>Deshalb möchte ich das Ganze nun anhand eines konkreten Beispiels erläutern, nämlich an unserer bereits bekannten Stadtbibliothek.</p><h3 class=„subheading“ id=„nav_einen_ausweis8“>Einen Ausweis beantragen</h3><p>Bevor Sie dort überhaupt etwas leihen dürfen, benötigen Sie zunächst einen Ausweis, eine sogenannte <em>Library Card</em>. Viele Entwicklerinnen und Entwickler würden vermutlich damit beginnen, dass man eine Library Card erstellen muss, also mit <code>CreateLibraryCard</code> – und schon befindet man sich wieder in der Denkweise von <em>Create</em>, <em>Read</em>, <em>Update</em> und <em>Delete</em>. Auch wenn das technisch später vielleicht korrekt sein mag, geht es zunächst doch darum, den Prozess aus <em>fachlicher</em> Sicht zu beschreiben.</p><p>Niemand würde eine Bibliothek betreten und sagen:</p><p class=„indent rteabs–indent“><em>„Created mir bitte einen Bibliotheksausweis!“</em></p><p>Stattdessen würde man wohl fragen, wie ein solcher Ausweis beantragt werden kann. Genau dies ist der erste Schritt unseres Prozesses. Die Frage lautet also: Welcher Begriff trifft das Ganze fachlich am besten? Die Formulierung „Ausweis beantragen“ passt aus meiner Sicht schon recht gut. Allerdings ist „Ausweis beantragen“ noch kein Event. Es müsste nämlich in der Vergangenheitsform stehen, also „Ausweis wurde beantragt“.</p><p>Das ergibt Sinn, denn wenn Sie sich vorstellen, abends nach Hause zu kommen und gefragt zu werden, wie Ihr Tag war, würden Sie ebenfalls in der Vergangenheitsform erzählen. Bei Bedarf lässt sich das Ganze dann schlussendlich noch ins Englische übertragen, was dann einem „Applied for a Library Card“-Event entsprechen würde.</p><p>Als Nächstes würde der Ausweis vermutlich ausgestellt. Vielleicht denken Sie jetzt:</p><p class=„indent rteabs–indent“><em>„Alles klar, dann haben wir aber jetzt ein Create.“</em></p><p>In der Vergangenheitsform wäre das ein „Library Card Created“-Event. Rein sprachlich wäre das korrekt, allerdings hatte ich erwähnt, dass der Ausweis <em>ausgestellt</em> wird. Einen Ausweis auszustellen bedeutet jedoch nicht „Create a Library Card“, sondern eher „Issue a Library Card“. Daher hätten wir also eher ein „Library Card Issued“-Event.</p><h3 class=„subheading“ id=„naves_ist_doch9“>„Es Ist doch egal, wie man das nennt!“</h3><p>Vielleicht wenden Sie nun ein, dass das letztlich Wortklauberei sei. Ob nun <em>create</em> oder <em>issue</em> – das sei doch egal, man wisse schließlich, was gemeint ist. Der springende Punkt ist jedoch: Das weiß man eben gerade leider nicht. Wir hatten gerade selbst die Situation, dass wir zwei verschiedene Ereignisse – nämlich das Beantragen und das Ausstellen des Ausweises – zunächst beide als <em>create</em> bezeichnen wollten. Hätten wir das getan, hätten wir nun bereits zwei Prozessschritte, die wir sprachlich nicht voneinander unterscheiden könnten.</p><p>Indem wir versuchen, fachlich passende und semantisch ausdrucksstarke Wörter zu finden, präzisieren wir unsere Sprache. Wir erhalten dadurch nicht nur ein genaueres Verständnis darüber, worum es fachlich geht, sondern nähern uns sprachlich auch der Fachabteilung an. Genau diese Kombination führt dazu, dass wir besser miteinander kommunizieren, Wünsche und Anforderungen besser verstehen und auf diese Weise letztlich in der Lage sind, bessere Software in kürzerer Zeit zu entwickeln.</p><h3 class=„subheading“ id=„nav_bessere10“>Bessere Kommunikation</h3><p>Wie viel hilfreicher ist nämlich bitte die Frage:</p><p class=„indent rteabs–indent“><em>„Okay, wir haben jetzt implementiert, dass man Ausweise beantragen kann und dass diese anschließend ausgestellt werden können, was ist der nächste Schritt?“</em></p><p>im Vergleich zu der Aussage:</p><p class=„indent rteabs–indent“><em>„Wir haben jetzt</em>
CreateAusweis
<em>implementiert, wir machen dann als Nächstes</em>
UpdateAusweis
.“</p><p>Ersteres bietet eine hervorragende Basis für ein zielgerichtetes Gespräch mit einer fachkundigen Person, während Letzteres eine vage, technische Äußerung darstellt, die kaum etwas aussagt und wahrscheinlich jede weitere Kommunikation verhindert.</p><h3 class=„subheading“ id=„nav_sprachliche11“>Sprachliche Präzision</h3><p>Dieses Prinzip, sprachlich präzise zu sein und fachliche statt technischer Begriffe zu verwenden, sollten wir konsequent fortführen: Ein Bibliotheksausweis allein bringt noch nicht viel, er bildet lediglich die Voraussetzung dafür, dass wir überhaupt Bücher ausleihen dürfen. Und genau das wäre vermutlich der nächste Schritt im Prozess: Ein Buch auszuleihen.</p><p>Nun stellt sich erneut die Frage, wie dieses Event genannt werden sollte. Sprechen wir einfach von einem <code>BookBorrowed</code>-Event? Oder existieren möglicherweise Unterschiede? Wird ein Buch beispielsweise sofort ausgeliehen, oder muss es erst reserviert werden, um es später abzuholen? Welche Bedingungen müssen erfüllt sein, damit die Ausleihe tatsächlich stattfindet? All das sind Überlegungen, die wir nur anstellen, wenn wir sprachlich präzise bleiben und uns eng an der Fachsprache orientieren, da uns genau das dazu zwingt, uns inhaltlich mit der Fachlichkeit auseinanderzusetzen. Dies ist gut. Auf diese Weise entstehen nach und nach die verschiedenen Events, die in der jeweiligen Fachdomäne eine Rolle spielen.</p><p>Ein weiterer Vorteil besteht darin, dass sich dies wunderbar gemeinsam umsetzen lässt: Die Entwicklungsabteilung und die Fachabteilung kommen zusammen, sodass ein Gespräch entsteht und beide in eine gemeinsame Richtung arbeiten. Es handelt sich nicht um ein Gegeneinander (wie es sonst so häufig der Fall ist), sondern um ein Miteinander. Die Fachabteilung hat schließlich ein Interesse daran, dass die Entwicklung versteht, worum es geht, denn nur dann kann sie eine adäquate und zielgerichtete Software erstellen. Dies gilt selbstverständlich auch in umgekehrter Richtung. Genau diese Herangehensweise – die Fachlichkeit in den Vordergrund zu rücken – macht das Prinzip so mächtig.</p><h3 class=„subheading“ id=„nav_domain12“>Domain Storytelling, Event Storming & Co.</h3><p>Vielleicht fragen Sie sich jetzt, ob es dafür nicht bereits einige fertige Workshop-Formate gibt. Tatsächlich existiert eine ganze Reihe, etwa Event Storming, Event Modeling oder Domain Storytelling. Diese Formate verfolgen jeweils einen etwas anderen Ansatz: Domain Storytelling eignet sich beispielsweise sehr gut dafür, überhaupt erst einmal einen Fuß in eine Fachdomäne zu setzen, während Event Storming und Event Modeling sehr in die Tiefe gehen und teils auch technische Details beleuchten.</p><p>Deshalb würde ich zumindest anfangs zu Domain Storytelling raten: Es ist zum Glück leicht zu erlernen, und es gibt ein interessantes <a href=„https://www.youtube.com/watch?v=EaKWQ1rsaqQ“ rel=„external noopener“ target=„_blank“>Buch zu diesem Thema</a>.</p><p>Letztlich spielt es jedoch keine große Rolle, welche dieser Methoden Sie verwenden oder ob Sie überhaupt eine davon nutzen. Wichtig ist nur, dass Sie eine gemeinsame Basis schaffen – mit einer gemeinsamen Sprache und einem gemeinsamen Verständnis. Der Weg dorthin ist letztlich zweitrangig. Nehmen Sie daher einfach das, was Ihnen am ehesten zusagt. Wählen Sie das, womit Sie sich wohlfühlen. Entscheiden Sie sich für das, wo Sie möglicherweise schon jemanden kennen oder finden, der Sie dabei unterstützt und den Prozess anleitet oder moderiert.</p><h3 class=„subheading“ id=„nav_die_kirsche_auf13“>Die Kirsche auf der Sahnetorte</h3><p>Vielleicht fragen Sie sich zum Schluss noch, warum Sie das alles speziell in dieser Event-Form gestalten sollten. Man könnte anstelle von „Ausweis wurde beantragt“, „Ausweis wurde ausgestellt“, „Buch wurde ausgeliehen“ und so weiter ebenso gut Formulierungen im Indikativ verwenden, also in der Grundform, beispielsweise „Ausweis beantragen“, „Ausweis ausstellen“, „Buch ausleihen“ und so weiter.</p><p>Die fachlichen Verben wären dort schließlich ebenfalls enthalten. Das ist im Grundsatz richtig, aber es gibt gewissermaßen noch einen Bonus, wenn Sie die Event-Form verwenden. Es ist sozusagen die sprichwörtliche Kirsche auf der Torte. Sobald Sie diese geschäftlichen Ereignisse in der Event-Form ausdrücken, erhalten Sie die ideale Ausgangsbasis, um die Events in einem geeigneten Protokoll zu speichern, ähnlich einem Logbuch.</p><p>Dies wiederum bietet eine Vielzahl von Vorteilen von einer deutlich besseren Transparenz darüber, was wann und warum von wem durchgeführt wurde, über ein integriertes Audit-Log bis hin zu sehr flexiblen Möglichkeiten für Analysen und Reports. Das kann man sich leicht vorstellen: Wenn Sie nur wissen, dass ein Buch gerade ausgeliehen ist, kennen Sie diesen Zustand, aber sonst nichts. Wenn Sie jedoch die komplette Historie kennen, die im Laufe der Zeit zum aktuellen Status quo geführt hat, können Sie unzählige Fragen beantworten, auch wenn Ihnen zuvor nicht klar war, dass diese Informationen später von Interesse sein würden. Dazu zählen Fragen wie:</p><ul class=„rtelist rtelist–unordered“><li>Wie oft im Jahr wird ein bestimmtes Buch ausgeliehen?</li><li>Welches Buch wird am häufigsten verlängert?</li><li>Wie viel Prozent der Personen, die sich einen Ausweis haben ausstellen lassen, nutzen ihn innerhalb der ersten vier Wochen, um mindestens drei Bücher auszuleihen?</li><li>…</li></ul><p>Diese Art der Datenspeicherung nennt man <em>Event Sourcing</em>, und dazu habe ich vor einigen Wochen <a href=„https://www.heise.de/blog/Event-Sourcing-Die-bessere-Art-zu-entwickeln-10258295.html“>bereits einen Beitrag geschrieben</a>. Der Vorteil daran ist, dass Sie gleich drei Fliegen mit einer Klappe schlagen, wenn Sie fachliche Prozesse konsequent als Events formulieren:</p><ul class=„rtelist rtelist–unordered“><li>Erstens erhalten Sie ein viel besseres Verständnis dafür, worum es in der Anwendung fachlich geht.</li><li>Zweitens verbessern Sie die Kommunikation mit der Fachabteilung, weil Sie plötzlich dasselbe Verständnis teilen und auch dieselben Begriffe nutzen.</li><li>Drittens legen Sie damit den Grundstein für eine moderne und flexible Architektur auf Basis von Event Sourcing und möglicherweise auch auf Basis von <a href=„https://www.youtube.com/watch?v=hP-2ojGfd-Q“ rel=„external noopener“ target=„_blank“>CQRS</a>.</li></ul><p>Übrigens war ich vor ungefähr zehn Tagen in einem sehr interessanten Podcast zu Gast – dem <a href=„https://engineeringkiosk.dev/podcast/episode/183-event-sourcing-die-intelligente-datenarchitektur-mit-semantischer-historie-mit-golo-roden/“ rel=„external noopener“ target=„_blank“>Engineering Kiosk</a> –, wo wir uns eineinhalb Stunden lang ausführlich über das Zusammenspiel all dieser Themen unterhalten haben. Wenn Sie das interessiert, schauen oder hören Sie dort gerne einmal vorbei.(<a class=„redakteurskuerzellink“ title=„Rainald Menge-Sonnentag“>rme</a>)</p> <div class=„paywall-delimiter“> </div> </div> </div></div></div> </html>
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International