Kohäsion

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Sven Johann: Ja, hallo und herzlich willkommen zu einer neuen Folge vom INNOQ Podcast. Heute mal wieder mit Michael Plöd. Hallo Michael.

Michael Plöd: Hallo Sven. Schön, dass ich mal wieder dabei sein darf.

Sven Johann: Ja, genau. Das letzte Mal ist ja schon eine Weile her, ne? War das letztes Jahr vor über einem Jahr oder so?

Michael Plöd: Oh, ich glaube, das war sogar schon länger.

Sven Johann: Ja, ich bilde mir ein, so Januar letztes Jahr zu Team Topologies oder Enabling Teams.

Michael Plöd: Oh ja, richtig, stimmt, da war was, ja. Richtig, ich erinnere mich, ja.

Sven Johann: Genau. Und jetzt, ich finde ein super interessantes Thema. Ich habe nämlich Kohäsion und du hast einen Vortrag über Kohäsion gemacht. Ich meine, wir reden alle, wenn wir über wartbare Software reden, immer über lose Kopplung und hohe Kohäsion und so weiter, aber irgendwie niemand redet über Kohäsion. Wie kamst du eigentlich dazu, einen Vortrag über Kohäsion zu machen?

Michael Plöd: Also ich glaube, die Hauptinspiration war das Buch und diverse damit korrespondierende Talks von Vlad Khononov zum Thema Kopplung. Vlad hat erstens das Learning Domain Driven Design Buch bei O’Reilly veröffentlicht und hat jetzt kürzlich in der Signature Series von Vaughn Vernon ein Buch veröffentlicht zum Thema Kopplung. Und da wurde mir eigentlich bewusst, dass wir verdammt viel über Kopplung reden. Ich schätze den Vlad ungemein, das ist ein super Typ und was der da an Tiefe produziert, sowohl in dem Buch als auch in den Talks, das ist total beeindruckend. Absolute Empfehlung sowohl für das Buch als auch für die Vorträge von Vlad zu dem Thema. Und irgendwie ist mir da aufgefallen, auch bei diversen Kundengesprächen, es dreht sich verdammt viel um Kopplung. Und irgendwie Kohäsion wird häufig als so ein wenig greifbares, abstraktes Ding wahrgenommen und ich habe dann mal angefangen, mich mal ein bisschen mit dem Thema in der Tiefe zu befassen, weil ich mir gedacht habe, vielleicht mache ich mal irgendwo was zum Thema Kohäsion und das war eigentlich so der Start an der Stelle. Und wenn man sich da mal intensiv befasst, stellt man eigentlich fest, dass sich sehr, sehr viele Themen im Bereich Modellierung, Design eigentlich sehr, sehr explizit mit dem Thema Kohäsion befassen und dass man Kohäsion extrem weit betrachten kann. Ja, und da auch sehr viele verschiedenste Punkte miteinander verbinden kann an der Stelle. Und so kam es dazu.

Sven Johann: Okay, okay. Ja, also ich muss auch sagen, ich habe später noch eine Frage, wo ich so eine kleine Peinlichkeit von meiner Seite zu Kohäsion loslassen kann. Bevor wir loslegen, du hast ja auch gesagt, das kann man unheimlich weit fassen. Ich würde vielleicht trotzdem erstmal weit anfangen und zwar, was ist überhaupt Kohäsion so im ganz Allgemeinen, also jetzt mal außerhalb von Software vielleicht?

Michael Plöd: Ja, also ich würde mal sagen, Kohäsion ist erstens mal, muss man ganz klar sagen, das ist kein reines IT-Thema. Kohäsion gibt’s in der Chemie, in Bodenbeschaffenheiten, in der Politikwissenschaft, in der Linguistik und in vielen verschiedenen anderen Disziplinen wird über Kohäsion gesprochen. Also das ist eigentlich gar kein reines IT-Ding. Original kommt der Begriff Kohäsion von dem lateinischen Verb cohaerere. Und da geht’s eben darum, wie sich Dinge berühren, wie Sachen zusammenpassen, wie Sachen zusammenheften, wie die Zusammengehörigkeit von bestimmten Elementen ist und das ist eigentlich was, egal welche Disziplin man betrachtet. Bei Bodenbeschaffenheiten, ja, es gibt Böden, die haben eine sehr hohe Kohäsion, so ein Lehmboden beispielsweise ist extrem kohäsiv, wohingegen natürlich ein Haufen Sand oder irgendein Treibsand relativ wenig Kohäsion hat. Wenn ich jetzt den Sand beispielsweise verdichte, erhöht sich seine Kohäsion. In der Politikwissenschaft geht’s bei Kohäsion darum, um dieses Thema Geschlossenheit einer Fraktion beispielsweise, also wie geschlossen tritt eine Fraktion auf, wie hoch ist das Gemeinschaftsgefühl, wie hoch ist der Grad der Zustimmung zu bestimmten Themen in dem Umfeld. Im Bereich Linguistik geht’s bei der Kohäsion darum, wie bestimmte Teile von dem Text oder von der Abhandlung so verbunden sind, dass sie eine Bedeutung erzeugen können. In der Chemie geht’s darum, wie ist die Anziehungskraft von verschiedenen Molekülen der gleichen Substanz zueinander. Ja, und da haben wir natürlich auch wieder eine Parallele zu der Bodenbeschaffenheitsthematik. Und in der IT geht es schlussendlich darum, ja, wie jetzt die Inhalte eines Moduls irgendwie zusammengehören. Ja, also das Zusammengehörigkeitsgefühl, also wie stark, ja, wie stark passt das Ganze zusammen. Also ich vergleich das immer gerne mit Restaurants, ja, also beispielsweise, wenn man jetzt durch irgendeine größere Stadt in Deutschland geht, dann sieht man in den Innenstädten immer irgendwelche Imbissbuden, die Sushi, Döner, Asia, Bratwurst, was weiß ich was, Schweinsbraten, Pizza und so weiter verkaufen. Also es ist jetzt ein sehr weit gefasster Kohäsionsbegriff an der Stelle. Jetzt habe ich beispielsweise ein italienisches Lokal, das bietet Pasta, Pizza, Tiramisu beispielsweise. Da ist so dieser Kohäsionsfaktor schon ein bisschen größer. Also es geht nur um italienisches Essen. Da kriege ich jetzt kein Sushi, da kriege ich jetzt auch nicht irgendwie, was weiß ich was, ein thailändisches Stir-fry oder sowas. Und dann gibt’s beispielsweise irgendwelche Läden, die haben sich nur auf Pizza Neapolitana fokussiert. Ja, die machen nur Pizza Napolitana. Also das heißt, da ist dieser Fokus noch mal stärker und das ist ja auch in der IT so. Da gibt’s diverse wissenschaftliche Studien und Abhandlungen, dass es auch verschiedenste Ebenen der Kohäsion gibt, also verschiedenste Stärken der Zusammengehörigkeit. Das ist kein binäres Ding, also kohäsiv, nicht kohäsiv. Ja, sondern da gibt es Abstufungen.

Sven Johann: Ja, ja, also Kohäsion tritt ja auch immer, sagen wir mal so, mit Kopplung im Zusammenhang auf und bei Kopplung ist ja im Grunde genommen auch so, ne? Da gibt’s nicht irgendwie hohe Kopplung, gibt keine Kopplung und es gibt hohe Kopplung, aber es gibt natürlich auch einen Haufen Graustufen. Jetzt hatte ich irgendwie am Anfang gesagt, warte mal schnell.

Michael Plöd: Da gibt’s einen total coolen Zusammenhang. Lass uns mal bei dem Thema Kopplung bleiben. Kopplung wird ganz häufig bei ganz vielen Teams, mit denen ich zusammenarbeite, eigentlich auf einer Ebene betrachtet. Also das heißt, indem wir die Beziehungen zwischen Modulen minimieren. Es gibt allerdings, wenn man beispielsweise das Structure Design Paper von Stevens, Myers, Constantine anschaut, aus der IBM Welt aus den er Jahren, die sagen, es gibt zwei Arten, zwei Wege, um eine lose Kopplung zu erreichen. Das eine ist das Minimieren der Beziehungen, was sehr, sehr häufig betrachtet wird. Die zweite Variante ist die Maximierung der Beziehungen von Elementen in einem Modul. Also das heißt, ich kann lose Kopplung durch Erhöhung der internen Kohäsion erreichen. Und ich glaube, da schauen wir viel zu selten drauf.

Sven Johann: Jetzt mal umgekehrt gefragt, kann man auch, also man kann keine hohe Kohäsion durch lose Kopplung erreichen?

Michael Plöd: Von der Seite habe ich es noch gar nicht betrachtet, muss ich gestehen. Ich glaube ehrlich gesagt, die beiden Sachen gehen Hand in Hand. Ich bin auch kein Freund von so einer Schwarz-Weiß-Denke, entweder so oder so. Ich glaube, wir müssen diese Themen sehr, sehr ganzheitlich betrachten. Ja, also ich sag mal, wir sollten uns Gedanken machen einmal über das Thema Kopplung natürlich auf dieser Beziehungsebene, aber natürlich auch über Kohäsion und ich glaube, wenn wir von diesen zwei Perspektiven her arbeiten, sind wir glaube ich auf einem ganz guten Weg.

Sven Johann: Mhm. Ja, also okay, jetzt fühle ich mich jetzt gar nicht mehr ganz so schlecht. Also weil die Peinlichkeit, über die ich berichten wollte, war eher so, ich hatte mal öffentlich behauptet, lose Kopplung und hohe Kohäsion, die gehören einfach zusammen. Also es sind einfach nur so zwei Seiten von derselben Medaille. Und dann hat ein sehr geschätzter Mensch von mir gesagt, Sven, das stimmt nicht. Und dann ist mir aber aufgefallen, ich kann gar nicht wirklich, also ich kann dem nicht sagen, doch, das stimmt, weil ich ja gar nicht so wirklich über Kohäsion überhaupt, also peinlicherweise so in meinem Leben nachgedacht habe, so intensiv. Also es stimmt ja natürlich jetzt nicht ganz. Aber als ich jetzt zum Beispiel deinen Vortrag, ich habe ja nur die Slides gesehen, habe ich, nee, ich habe wirklich nie darüber nachgedacht. Deswegen bin ich auch ziemlich froh jetzt mal darüber zu quatschen.

Michael Plöd: Also ich bin immer kein großer Freund von solchen Sachen, gerade jetzt im Modellierungsumfeld und Designumfeld, von zu sagen, das stimmt, das stimmt nicht. Ich glaube, wir sollten viel weniger über solche, ich sag, das ist so ein bisschen für mich so ganz häufig so eine Template-Denke und ich denke, wir sollten eigentlich viel mehr in Richtung Heuristiken denken. Und ich glaube, in sehr vielen Fällen gehen die beiden Hand in Hand miteinander, aber natürlich kann ich beide auch mal isoliert betrachten. Aber meine tiefste Überzeugung ist, dass ein gutes Design, also vor allem, was ist ein gutes Design? Ein gutes Design ist eines, das in die Umstände reinpasst, das funktionale Sachen berücksichtigt, das natürlich die funktionalen Anforderungen erfüllt, das in die Qualitätsanforderungen reinpasst, das aber auch zur Organisation des Unternehmens passt und der Kundenstruktur passt, etc. Und ich glaube, da gibt’s so viele Treiber oder Stressoren für sowas, dass ich glaube, so dieses das stimmt, das stimmt nicht, eine ganz schwierige Diskussion ist. Ich glaube eher, wir müssen dann nuancierter über die Sachen denken und ich glaube, wenn wir mal, ich sag mal mit einer sehr, sehr breit gefächerten Linse auf die Sachen schauen, ich glaube, dann destillieren sich einfach Sachen, die passend sind, oder ich bin ganz großer Freund von dieser George EP Box Quote: All Models are wrong, but some are useful. Und ich glaube, wenn wir das so mit einer breiten Linse drauf schauen und verschiedenste Treiber und Stressoren für so ein Design betrachten, ich glaube, dann bewegen wir uns in Richtung useful und ich bin ein Freund von useful.

Sven Johann: Ja. Okay. Genau, also jetzt im Sinne von useful, wir würden auf jeden Fall sagen, okay, so eine hohe Kohäsion ist auf jeden Fall zumindest mal in Software erstrebenswert. Ich habe auch gedacht, na ja, eigentlich bei Restaurants ist es auch erstrebenswert, ne? Also, wenn man so ich biete Pizza, Indisch und Griechisch an, das kann nichts werden.

Michael Plöd: Es kommt darauf an, welchen Zweck du erfüllen willst. Wenn du die bestmögliche Pizza Neapolitaner essen willst, bist du wahrscheinlich in einem Restaurant, das sich sehr stark darauf spezialisiert hat, sehr gut aufgehoben. Wenn du auf so etwas aus bist, dann ist diese Pizza-, Sushi-, Dönerbude nicht unbedingt die beste Adresse. Bist du allerdings mit einer Gruppe Freunde unterwegs, wo eine Person Sushi essen will, eine Döner und die nächste Pizza, dann erfüllt so etwas wahrscheinlich eher den Zweck dieser Gruppe. Ich persönlich würde auch lieber in das Pizza Neapolitana Restaurant gehen. Für mich ist die Heuristik: Wer wirklich gut essen will, meidet diese ganz breit gefächerten Läden, weil sie alles machen, aber nichts gescheit. Aber es gibt schon Zwecke, die sie erfüllen.

Michael Plöd: Im Bereich Kohäsion ist Zweck ein ganz spannendes Thema an der Stelle.

Sven Johann: Was? Jetzt bin ich so ein bisschen verloren. Hol mich mal ab. Was wäre so ein Beispiel?

Michael Plöd: Ich will auf eine Sache hinaus. Es gibt verschiedenste Arten oder Ebenen von Kohäsion. Dazu gibt es zwei sehr populäre Veröffentlichungen. Das ist einmal etwas aus diesem Structured Design Paper, man nennt es SMC Cohesion. SMC steht für Stevens, Myers, Constantine, das sind die drei Autoren dieses Papers aus den er Jahren. Und es gibt noch ein Paper von der Colorado State University, das nennt sich Design Level Cohesion Measures. Das ist ein sehr mathematisch getriebenes Modell rund um Kohäsion in Softwaresystemen, und die kennen beispielsweise sechs Ebenen. Man kann sagen, SMC richtet sich eher an Leute, die Software designen, und DLC wird gerne für diejenigen verwendet, die Metriken für die Kohäsion entwickeln, weil es ein sehr mathematisch getriebenes Modell ist. Was die eint: Sie kennen verschiedenste Ebenen. SMC kennt beispielsweise sieben Ebenen. Die unterste ist Coincidental Cohesion. Das ist die typische Util-Klasse, da schmeißt man alles rein, wo man nicht genau weiß, was das Ding tun soll. Das kann XML parsen, eine Mail versenden und ein Scoring für einen Kredit berechnen beispielsweise. Das ist völlig Coincidental. Und die höchste Stufe ist Functional Cohesion. Da geht es um den funktionalen Zusammenhalt, und der Kerntreiber ist der fachliche Zweck eines Moduls. Wir wollen eigentlich Functional Cohesion in unserer Software erreichen. Das ist die stärkste Form von Kohäsion, die es gibt, und der Treiber dafür ist der fachliche Zweck eines Moduls. Können wir den Zweck, den Purpose, wie es in dem Paper heißt, eines Moduls sehr klar in einem Satz beschreiben? Welchen Zweck will ich denn verfolgen? Es gibt beispielsweise Heuristiken, wo ich diesen Zweck aufschreibe und dann den Satz analysieren kann und sagen kann, wenn ich diese Heuristiken darauf setze, wie stark deutet das auf eine funktionale oder eine Functional Cohesion hin? Taucht in dem Satz beispielsweise ‘und’, ‘Komma’, ‘sowie’, ‘als auch’ etc. auf, ist das ein Indikator, dass die Kohäsion vielleicht doch nicht ganz so hoch ist. Um das Thema Zweck dreht sich an der Stelle sehr viel, und deshalb habe ich auch ganz bewusst bei dem Restaurantbeispiel darauf herumgeritten.

Sven Johann: Ja, genau.

Michael Plöd: Welchen Zweck wollen wir denn überhaupt erfüllen? Was ist unsere Perspektive beim Entwurf eines Systems oder beim Entwurf eines Restaurants im Hinblick auf den Zweck, der erfüllt werden soll? Ist es die bestmögliche Pizza Neapolitana oder ist es ein möglichst breit gefächertes Angebot für verschiedenste Geschmäcker einer wild zusammengewürfelten Gruppe bei einem Kneipenabend abzudecken?

Sven Johann: Da war jetzt kein ‘und’ dabei, oder? Bei dem letzten.

Michael Plöd: Ich habe den Zweck so formuliert, dass er aus dieser Perspektive trotzdem funktional sein kann. Es ist eine Frage der Betrachtung derjenigen, die das definieren.

Sven Johann: Ich würde vielleicht noch mal, du hast ja diese sieben Level genannt. Vielleicht können wir mal ganz kurz drüber gehen, damit jeder so eine Idee hat. Zufällig erkenne ich, ja, da bin ich in der Foundation Level Schulung. Bringe ich auch immer Java Util, stelle ich immer die Frage: Java Util contains the Collection Framework, Internationalization Support, Service Loader, Properties, Random Number Generator, String Parsing und so weiter und so weiter, kommen noch irgendwie andere. Und die Frage ist, hat eine hohe Kohäsion? Und da ist natürlich immer das Gelächter groß, natürlich nicht.

Michael Plöd: Ich hatte als Entwickler eine Historie, Util-Klassen in Trash Dump umzubenennen.

Sven Johann: Bitte, Util-Klassen in was umzubenennen?

Michael Plöd: Util-Klassen umbenennen in den Namen Trash Dump.

Sven Johann: Ah, okay.

Michael Plöd: Damit man sich überlegt, wie ich da wirklich was reinprogrammiert. Weil die haben ja häufig so eine Anziehungskraft: Wir wissen nicht, wo man das hintun, tun wir es mal in die Util-Klasse. Später explodieren die Dinger halt.

Sven Johann: Ja. Also Dave Thomas, der Smalltalk Dave, der sagt halt immer Kitchen Sink, da kannst du irgendwie alles reinwerfen.

Michael Plöd: Genau.

Sven Johann: Das passt schon. Oder Core, finde ich. Früher gab es immer diese Core Packages, und irgendwann hatte das Projekt nur noch aus Core bestanden und so ein paar dünnen Rand.

Michael Plöd: Das klingt ja auch total super, Core. Absolut Spitze.

Sven Johann: Ja, ich bin im Moment auch in einem Core Team.

Michael Plöd: Oh. Sehr schön.

Sven Johann: Ja. Aber das Team funktioniert ziemlich gut, muss ich sagen. Genau, also die zufällig, ja, ist das eine. Der praktisch die zweite Ebene. By the way, ich habe mir die Ebenen aufgeschrieben und ich war mir gar nicht so sicher, ist jetzt fünf besser als sechs, aber die Frage hast du schon beantwortet, Ebene sechs ist besser als Ebene fünf. Genau, was ist denn Ebene zwei?

Michael Plöd: Ebene zwei ist die Logical Cohesion. Da geht es darum, dass die Elemente von dem Modul zusammenhängen bei einer bestimmten Kategorie oder Funktionsart. Man könnte jetzt beispielsweise sagen, ich habe so ein Read Package, und da ist Funktionalität drin, dass ich XML Files lesen kann, Event Streams lesen kann, Daten aus einer Neoj lesen kann, HTTP Feeds lesen kann. Also da ist quasi dieser Kohäsionsfaktor lesende Operationen, das heißt, der Typ oder die Kategorie ist ‘Zeug lesen’. Das ist die Logical Cohesion, das ist die zweite Ebene. Ich habe übrigens auf meinem GitHub Account, github.com/plöd, ein öffentliches Beispielprojekt liegen, wo ich mal all diese Kohäsionsebenen ausprogrammiert habe auf einer Klassenebene und auf einer Package Ebene. Wer sich das da mal anschauen will, kann da gerne drauf schauen, und da ist es auf einer Code Ebene auch noch mal ein bisschen erläutert.

Sven Johann: Genau. Habe ich mir sogar angeguckt, also ich kann es auf jeden Fall unterstützen. Ich muss dazu sagen, in der Foundation Level Schulung, die wir haben, da haben wir auch so, haben wir im Prinzip auch so, wie kommt man von Use Cases, haben wir so eine Slide, wie man von Use Cases eigentlich zu Komponenten kommt. Und diese Slide will ich irgendwie schon seit drei Jahren ändern oder so, weil ich der Meinung bin, das tut mir weh, wenn ich diese Gruppierung sehe. Und als ich dann dein Beispiel gelesen habe mit dem Read, da musste ich so zusammenzucken, weil wir genau da, wir haben halt diese Read Komponente da drin so ungefähr.

Michael Plöd: Logical Cohesion, ja.

Sven Johann: Ja, jetzt muss ich ran, habe ich gedacht. Genau, jetzt muss ich ran. Okay. Was wäre denn die dritte Ebene?

Michael Plöd: Die dritte Ebene nennt sich Temporal Cohesion. Da geht es darum, dass wir dort Elemente und Funktionalitäten zusammen gruppieren, die zur gleichen Zeit zusammen ausgeführt werden müssen. Da geht es um den Zeitpunkt und nicht um den Inhalt. Das typische ist so beispielsweise ein End of Month Modul oder ein End of the Year Processing Modul oder irgendwie so etwas, wo man beispielsweise irgendwelche Transaktionslogs archiviert, Datenbank Backup durchführt, die letzten finanziellen Transaktionen abschließt etc. Und da geht es eben genau um einen Zeitpunkt oder was zum Application Startup passieren muss, was zum Application Shutdown passieren muss, solche Sachen. Also da ist der Zeitpunkt der Treiber für die Zusammengehörigkeit von Operationen und von Funktionalität.

Sven Johann: Mhm. Ich muss schon wieder innerlich zusammenzucken, weil mir fallen jetzt wieder so viele Sachen ein, wo ich genau das gemacht habe. Gerade so Reports oder so, ne?

Michael Plöd: Vierte Ebene ist die Procedural Cohesion. Da geht es darum, dass wir Elemente in dem Modul zusammen gruppieren, die immer in einer ganz spezifischen und präzisen Sequenz im Hinblick auf die Ausführung ausgeführt werden müssen. Was weiß ich was. Schöner Zweckssatz: Zuerst machen wir das, dann machen wir das und dann machen wir jenes und abschließend passiert dieses. Das ist diese Form der Kohäsion, also die Procedural Cohesion. Da geht es um die Ausführungsreihenfolge, wohingegen bei der Temporal natürlich ein bestimmter Zeitpunkt interessant ist, und das ist die Nuancierung an der Stelle. Bei der Temporal ist es: Zum Zeitpunkt X muss das und das und das passieren. Und bei der Procedural ist: Hintereinander passiert dieses, dann jenes und dann das jene.

Sven Johann: Ja, was wäre das so konkret? Ich stelle mir das so vor, ich klicke auf einen Kaufen Button.

Sven Johann: Und dann versende ich, das erste was passiert, ich versende eine Mail.

Michael Plöd: Ja.

Sven Johann: Dann, also im Prinzip so eine Art Workflow, oder?

*Michael Plöd: Richtig, genau, ein Workflow. Ich habe in meinem Talk beispielsweise ein Beispiel gewählt für ein Modul, das Gehälter von Mitarbeiterinnen und Mitarbeitern berechnet. Zuerst sammeln wir mal die Arbeitsstunden der Leute ein. Dann berechnen wir, welche Steuerabzüge es gibt. Dann berechnen wir Brutto- und Nettogehalt. Dann überweisen wir das Geld auf die Konten. Wir generieren die Gehaltsabrechnung und schicken die dann abschließend per Mail an die Mitarbeiterinnen und Mitarbeiter beispielsweise. Also zack zack zack, wie die Sachen eben hintereinander ablaufen. Das ist die Procedural Cohesion.

Sven Johann: Ja, die hört sich für mich jetzt gar nicht so verkehrt an, muss ich sagen. Bei den anderen beiden kann ich nachvollziehen, dass ich zusammenzucke, aber da, das hört sich, da würde ich jetzt zum Beispiel sagen, ach ja, hört sich eigentlich richtig an. Aber wir könnten ja vielleicht noch mal. Wir gehen mal die ganze Leiter durch.

Michael Plöd: Ja, vielleicht einigen wir uns, die hört sich einfach besser an.

Sven Johann: Genau, auf jeden Fall.

Michael Plöd: Ja, da stehen wir irgendwie ein bisschen besser da, ja, wenn wir das so.

Sven Johann: Genau, und ich persönlich, ich fühle mich auch gar nicht schlecht, wenn ich so etwas habe. Habe ich neulich noch gemacht, haben wir so einen Distributed Workflow gehabt, haben wir einen Orchestrator gehabt, der macht halt genau diese Dinge. Fühle ich mich gut dabei, so etwas zu tun. Bei so temporal oder logisch fühlt man sich schon, tut es weh. Aber hier hätte ich jetzt auch gesagt, ich fühle mich besser. Also eigentlich fühle ich mich gut, ich fühle mich gut.

Michael Plöd: Vielleicht wird es ja noch besser.

Sven Johann: Vielleicht kann ich mich einfach noch viel besser fühlen, zum Beispiel mit dem fünften Communicational.

Michael Plöd: Communicational Cohesion ist in meinen Augen der Kohäsionslevel aus dem SMC Paper Structural Design, der am unglücklichsten benannt ist. Persönliche Meinung. Ich bin mir sicher, die Verfasser dieses Papers haben sich etwas dabei gedacht. Aber irgendwie ist der Name ein bisschen schwierig. Es geht nämlich darum, dass wir Elemente in dem Modul zusammen gruppieren, die auf den gleichen Daten agieren. Wir haben einen bestimmten Datensatz und wir führen auf dieser Ebene bestimmte Operationen aus, beispielsweise, dass ich auf einem Produktinventar ein Management Modul baue, wo ich bestimmte Mengen updaten kann, wo ich einen Report generieren kann, was man nachbestellen muss, wo ich bestimmte Reports abrufen oder Queries starten kann, wie viel Inventar wir beispielsweise haben. Es geht darum, der Bezug ist der identische Datensatz, und das hört sich schon wieder ein bisschen besser an. Wenn wir Objektorientierte Programmierung sagen, wollen wir Funktionalität möglichst nah an bestimmte Daten legen, das hört sich auch wieder ein bisschen besser an. Warum das jetzt Communicational heißt, erschließt sich mir ehrlich gesagt nicht so ganz.

Sven Johann: Es dreht sich rund um Daten. Ich musste automatisch, als ich das gelesen habe, an unseren gemeinsamen Bekannten Alard Bauze denken. Er hatte genau diese Denkweise.

Michael Plöd: Ich glaube, dass uns Objektorientierte Analyse und Design, also OOAD, nicht selten in diese Form der Kohäsion treibt. Ich kann mich noch erinnern, wo ich an der Uni war, da war eines der Standardbücher an der Universität ‘Objektorientierte Analyse und Design mit UML’ von Bernd Österreich. Das war ein Klassiker.

Sven Johann: Habe ich zu Hause liegen.

Michael Plöd: Das haben sämtliche alte Häsinen und Hasen in dem Geschäft in der Hand gehabt und gelesen. Die da stark propagiert wurde, wenn du einen Text liest, da erinnere ich mich noch heute an der Uni: Wenn du einen Text liest, streich die Substantive an, das sind wahrscheinlich Kandidaten für die Klasse. Dann überleg, welche Attribute haben die. Und als drittes überleg, welche Methoden brauchen wir dafür. Substantiv Attribute ist eine sehr starke datengetriebene Perspektive und wir hängen dann die Methoden drauf, und ich glaube, wenn wir datengetrieben modellieren, enden wir sehr häufig bei dieser Form der Kohäsion. Es gibt natürlich keinen Podcast, keinen Vortrag, wo ich nicht auf mein Herzensthema Domain Driven Design zu sprechen komme. Die Domain Driven Design Welt dreht es um. Wenn man einen Event Storming Workshop oder Domain Storytelling als Modellierungsmethodik betrachtet, sind das Methodiken, die sehr stark auf Verben fokussieren. Ein Domain Event muss ein Verb in Vergangenheitsform enthalten. Im Domain Storytelling gibt es auch diese Activities als prominentes Teil. Ich glaube, das ist eine Perspektive, die davon weggeht. Wir haben da sehr viel in Richtung von Communicational Cohesion modelliert.

Sven Johann: Ich frage mich, ob ich mit meiner Aussage daneben gelegen habe, weil Alard Mister DDD ist. Er war bei der ersten Schulung von…

Michael Plöd: Eric Evans.

Sven Johann: Von Eric Evans, in New York . Für mich liegt ein Aggregate doch nicht so daneben, oder?

Michael Plöd: Ich glaube, ein Aggregate halte ich für ein schwieriges Beispiel, weil ein Aggregate eine Konsistenzgrenze ist. Es geht stark darum, dass wir eine Grenze schaffen, wo bestimmte Informationen zu einem bestimmten Zeitpunkt absolut konsistent sein müssen. Es geht stark um diesen Konsistenzteil, und ich denke, ein Aggregate ist ein Pattern aus dem Tactical Design, das auf einer sehr tiefliegenden Ebene eines Systemdesigns liegt. Wir kommen später zu einem anderen Konstrukt, welches stark auf Functional Cohesion optimiert aus der DDD Welt ist. Ich glaube, beim Aggregate ist der Kohäsionstreiber, welche fachlichen Regeln zusammenlaufen müssen, um einen konsistenten Stand zu erreichen.

Sven Johann:

Michael Plöd:: Kann potenziell in diese Richtung gehen, aber es ist auf einer sehr tiefliegenden Ebene im Systemdesign.

Sven Johann: Alright.

Michael Plöd: Springen wir auf Level sechs.

Sven Johann: Alles wird besser, Level sechs.

Michael Plöd: Level sechs, Sequential Cohesion. Es geht darum, dass der Output eines Elements Input für ein anderes Element ist. Jede Unix Linux Shell setzt Sequential Cohesion um. LS Pipe Grab Pipe Sort Pipe Filter. Diese ganzen Pipe and Filter Architekturen gehen sehr stark in Richtung Sequential Cohesion. Ein Output von einem Element ist der Input für das nächste. Die bauen aufeinander auf. Das ist die Sequential Cohesion.

Sven Johann: Wenn ich Pure Functional entwickeln würde,

Michael Plöd:

Sven Johann: Würde es in die Richtung gehen?

Michael Plöd: Potenziell. Ich bin im Bereich der funktionalen Programmierung wahrscheinlich eine der schlechtmöglichsten Personen, die man fragen kann, weil ich mich da als gänzlich inkompetent betrachte. Was ich mitbekommen habe, könnte ich mir das vorstellen, aber ich würde meine Aussagen zu diesem Thema nicht auf eine Waagschale legen oder mich da zitieren wollen. Das wäre eine spannende Diskussion mit Mike Sperber beispielsweise.

Sven Johann: Ich kann mich erinnern, ich hatte diese Woche eine Schulung.

Michael Plöd: Oder Scott Laschen, ein spannender Kandidat für eine Frage.

Sven Johann: Ich hatte diese Woche eine Schulung gegeben, und da war ein Teilnehmer dabei, der, weil du Mike Sperber genannt hast, der Haskell-Entwickler schlechthin war. Er hat übrigens auch Mike Sperber empfohlen, um sich da zu informieren.

Michael Plöd: Super.

Sven Johann: Damit Sequential, da komme ich gut mit klar. Ich bilde mir ein, Pure Functional kann ich mir gut vorstellen, aber du sagst Unix Pipes, man kann sagen, jede Umsetzung vom Pipes and Filter Pattern,

Sven Johann: wäre sequentiell. Ich mache Pipes und Filter und dann ist es.

Michael Plöd: Sequential.

Sven Johann: Da fühle ich mich gut.

Michael Plöd: Schön, dass du dich gut fühlst.

Sven Johann: Die Frage ist, wie man sich am allerbesten fühlen kann. Obwohl ich gleich auf deinen Zweck zurückkommen würde, ist die höchste Stufe Functional. Was bedeutet das?

Michael Plöd: Es geht darum, dass die Elemente von dem Modul zusammen gruppiert sind, weil sie alle dazu beitragen, einen klar definierten Task zu erledigen. Beispielsweise haben wir ein Modul für das Scoring eines Baufinanzierungsantrags, und der Task ist, wir wollen eine Indikation über die potenzielle Genehmigungsfähigkeit eines Baufinanzierungsantrags berechnen. Es gibt ein Ampelergebnis: rot, gelb, grün. Rot ist die Aussage, da lassen wir die Finger davon, das machen wir nicht. Gelb ist, unter Vorbehalt könnte man machen. Grün ist, den Kredit könnte man gewähren. Das ist ein bestimmter Task, und da sind wir bei diesem Zweck. Wenn wir diesen Task, diese Aufgabe, was ist der Zweck dieses Moduls, beschreiben können, haben wir eine starke Indikation in Richtung der funktionalen Kohäsion.

Sven Johann: Ich muss an das Beispiel Procedural denken mit der Berechnung des Gehalts.

Michael Plöd:

Sven Johann: Wäre das nicht funktional, der Zweck ist, ich will Gehalt bezahlen, auszahlen oder Gehalt berechnen?

Michael Plöd: Ich glaube, der Zweck ist primär der Prozess. Wir müssen erst das machen, dann das. Aber wenn du auf die Aufgaben schaust, Steuern berechnen, Steuern ermitteln, ist für sich schon eine riesengroße Aufgabe. Eine E-Mail versenden ist etwas ganz anderes, oder ein PDF mit dieser Gehaltsabrechnung zu erstellen, oder das Ermitteln von Arbeitsstunden. Das ist auf einer funktionalen Ebene schon ein Gemischtwarenladen. Überleg, du würdest als Entwicklerin oder Entwickler in einem Team arbeiten, du musst Steuern-Know-how haben, du musst Arbeitsstunden wissen, wie du das aggregierst, du musst wissen, wie du ein rechtlich konformes Schreiben schreibst, wie du eine Finanztransaktion machst. Von der kognitiven Belastung der Gruppe an Leuten, die an einem Modul arbeiten, ist es schon eine ziemlich üble Kiste. Das sind Sachen, die wir woanders auslagern, und dann ist dieser Kohäsionsteil dieses Aneinanderreihen. Die Frage ist, was ist dein Treiber für das Schneiden der Module, und bei dieser sequenziellen Sache steht primär diese Sequenz der Operationen im Fokus, also bei der Procedural Cohesion. Ich finde Procedural und Sequential kann man schnell verwechseln. Man muss aufpassen.

Sven Johann: Ich habe es verwechselt.

Michael Plöd: Ich verwechsle es ständig, aber ich habe eine Ausrede, das ist mein Nachname.

Sven Johann: Habe ich Sequential gesagt, habe ich nicht Procedural gesagt?

Michael Plöd: Ich weiß es nicht. Ich habe vorhin diese sequenzielle gesagt, und in dem Moment, wo ich es gesagt hatte, habe ich mir gedacht: Vorsicht, aufpassen, ich muss das richtig stellen.

Sven Johann: Jetzt komme ich auf jeden Fall noch mal auf Procedural zurück, weil ich mir gerade eine Notiz gemacht habe. Ich muss nämlich an den Pizza-Sushi-Fall denken, wie auch immer, wo der Zweck entscheidend ist. Weil ich ja gesagt habe, wir haben hier zum Beispiel einen Distributed Workflow bei einem unserer Kunden, wo wir gemeinsam abhängen. Diesen Distributed Workflow haben wir mit einem Orchestrator umgesetzt. Der Orchestrator macht natürlich irgendwelche wilden Dinge, die eigentlich, ich sage jetzt mal, eine Mail schicken, dem Lager Bescheid sagen – das ist natürlich im Versicherungsfeld, aber ich will nicht zu detailliert darauf eingehen – aber er macht halt sehr unterschiedliche Sachen. Er macht sehr viele unterschiedliche Dinge. Ich habe gesagt, okay, das ist vielleicht nicht so toll, aber der Zweck, den wir haben, ist Zuverlässigkeit. Wir wollen diesen Workflow zuverlässig haben. Und da habe ich wieder gedacht, das ist ja eigentlich gar nicht so verkehrt.

Michael Plöd: Ich stecke jetzt in der Diskussion nicht so tief drin, aber wenn das der Zweck ist, wenn ihr das so definiert, gibt es wahrscheinlich sehr gute Gründe dafür, das zu tun. Ich glaube ehrlich gesagt, was ich an der Stelle gerne rate, ist: Lasst uns erstmal versuchen, ein System funktional zu schneiden, also ganz stark in Richtung Functional Cohesion optimiert. Vielleicht gibt es Module, wo wir sagen, da haben wir einen Orchestrator, den man aus welchen Gründen auch immer braucht. Der halt jetzt nicht funktional geschnitten ist, sondern wo ich dann eher in Richtung eines Schnitts aus einer Procedural Cohesion gehe, also dass man so ein Portfolio hat. Das ist für mich ehrlich gesagt völlig okay. Ich würde erstmal versuchen, funktional zu schneiden, und dann, wenn wir damit nicht weiterkommen, aus welchen Gründen auch immer, kann ich an ein paar Stellen davon abweichen. Das ist in Ordnung. Wir sind jetzt nicht dazu da, eine übermäßige wissenschaftliche Korrektheit in Systemen zu erzielen oder eine möglichst hohe DDD Compliance oder was weiß ich was zu erzielen, sondern wir sind als Architektinnen und Softwareentwickler da, um Probleme zu lösen. Das ist es ja, und die halt nachhaltig im Idealfall auch zu lösen. Ich bin immer ein Freund davon, erst einmal zu versuchen, das möglichst stark in diese Richtung zu treiben. Und dann situativ, wenn wir gute Gründe dafür haben, einfach davon abzuweichen, davon geht die Welt nicht unter. Bloß wenn wir natürlich in einem totalen Laissez-faire arbeiten und sagen, alles egal, und dann sind wir halt Coincidental, was soll’s, wir sind ja ultra pragmatisch oder was weiß ich, das halte ich dann natürlich schon für schwierig. Das würde ich jetzt nicht unbedingt tun.

Sven Johann: Das böse Wort. Eigentlich ein gutes Wort, aber wird zu oft missbraucht.

Michael Plöd: Welches gerne missbraucht wird.

Sven Johann: Ja, genau. Okay, ich bin überzeugt, ich will Functional Cohesion. Welche Methodiken gibt es denn, um Functional Cohesion zu erreichen?

Michael Plöd: Ich denke, die Methodik, die das am prominentesten aufgreift, ist Domain Driven Design. Wenn man zum Beispiel in das Buch von Eric Evans schaut, gibt es dieses Konstrukt des Bounded Context, und ich zitiere jetzt mehr oder minder wörtlich aus dem Buch von Eric: A model in a bounded context should have high cohesion, meaning that it forms a coherent whole around a single unified purpose. Übersetzt: Das Modell in einem Bounded Context sollte eine hohe Kohäsion haben. Das bedeutet, es bildet ein kohärentes Ganzes um einen bestimmten fachlichen Zweck. Oder eine andere Sache, was ich gerne als Definition vom Bounded Context verwende: Bounded Context ist die Grenze um ein fachliches Modell, das eine konsistente Sprache ist, das diese Ubiquitous Language hat und welches auf einen bestimmten Zweck zugeschnitten ist. Und da springt uns diese Idee der funktionalen Kohäsion voll entgegen. Genau darum geht es bei dem Bounded Context. Der Treiber für eine Functional Cohesion ist, dass wir einen einzigen, klar definierten Task haben, den wir möglichst präzise und möglichst klar beschreiben können. Und der Bounded Context, diese Idee greift genau an der Stelle an. Man redet auch im Kontext von Domain Driven Design immer von loser Kopplung, aber Eric Evans im DDD Buch redet eigentlich verdammt viel über hohe Kohäsion. Was gerne übersehen wird.

Sven Johann: Geht es auch ein bisschen kleiner? Ich denke jetzt zum Beispiel an eines unserer Systeme. Wir haben einen Bounded Context, und ich würde sagen, wir haben da eine hohe Kohäsion, es dreht sich alles um Anträge. Aber innerhalb dieses Bounded Context, wenn man sich die Struktur anguckt, denke ich, das kann nicht gut sein, so wie wir da arbeiten.

Michael Plöd: An der Stelle kann man natürlich auch den Zweck von bestimmten Grenzen innerhalb verschieben. Beispielsweise kann man auch hier die Sache auf kleinere, funktional getriebene Zwecke rund um Anträge herunterbrechen. Eine Möglichkeit – und ich möchte an der Stelle sehr deutlich sein, eine Möglichkeit und nicht die einzige, also eine von mehreren – wäre beispielsweise Aggregates zu definieren. Das heißt, ich überlege im Umfeld von einem Antrag, welche Teile wirklich sehr konsistent sein müssen. Wo haben wir bestimmte Regeln, sei es Validierungen, Berechnungen, Durchläufe, die zu einem konsistenten Ergebnis führen und die dann kombiniert den Antrag in Summe abbilden. Das ist eine Möglichkeit. Ich sage immer wieder gerne, es hat viel mehr mit Domain Driven Design zu tun, wenn ich in einem Bounded Context feststelle und sage, mir bringt das Pattern des Aggregates nichts. Es löst meinen fachlichen Zweck nicht, und ich lasse es weg, im Vergleich dazu, dass ich versuche, mit aller Gewalt Aggregates einzuführen, bloß weil die in dem blauen Buch standen. Für mich ist das ein optionales Pattern. Das ist eine coole Sache, total spannend, aber wie bei allen Patterns gibt es eine Problemstellung, die da beschrieben ist. Habt ihr das Problem? Nutzt das Pattern, eine total coole Sache. Habt ihr das Problem nicht, ist das Pattern vielleicht nicht hilfreich. Bitte geht nicht her und sagt, um Domain Driven Design zu machen, müssen wir mit aller Gewalt Aggregates verwenden. Nein, auf gar keinen Fall. Das ist jetzt aus diesem Methodik-Baukasten beispielsweise eine Möglichkeit, so etwas zu tun, oder man geht eben her und findet andere Sachen, die an der Stelle beitragen. Wobei, ich sage mal so, wenn du jetzt sagst Antrag, lass mich das gerne herausfordern. Kann es vielleicht sein, dass das nicht eigentlich auf eine Communicational Cohesion hindeutet? Wir bündeln Operationen, die alle am gleichen Datensatz stattfinden. Könnte gegebenenfalls sein. Das würde ich mal kritisch hinterfragen an der Stelle.

Sven Johann: Ich würde sagen, das könnte nicht nur so sein, sondern natürlich dreht sich alles rund um diese Daten, die in dem Antrag stecken. Es ist auch nicht so, dass wir klassisch Spring haben, wo es irgendwelche Services gibt, die auf Daten herumrödeln und nicht mal OO-mäßig sind. Das kann sein.

Michael Plöd: Das könnte auch durchaus sein, dass das Ding nicht funktional gebunden ist, um es mal auf Englisch auszudrücken.

Sven Johann: Nein, da würde ich sagen, auf gar keinen Fall. Okay, du sagst im Grunde genommen, wenn ich hohe Kohäsion, also Functional Cohesion haben will, ist eine Idee: Guck einfach in der DDD Toolbox, und zwar Top-to-Bottom, wie komme ich auf Bounded Contexts, wie kann ich Aggregates finden? Okay.

Michael Plöd: Richtig. Kleiner Tipp am Rande: Es gibt ein GitHub-Projekt oder eine GitHub-Organisation, die sich DDD Crew nennt, also github.com/ddd-crew. Das sind verschiedenste sehr aktive Leute aus der Domain Driven Design Community zusammen, darunter Marco Heimeshoff, Kenny Baas, Schwieger, Christina Hirt und ganz viele andere, ich bin da auch bei dem Haufen mit dabei, Nick Tune beispielsweise. Wir publizieren da ganz viel Methodik-Zeug unter einer Creative Commons Lizenz, und eine der Techniken, um Bounded Contexts identifizieren zu können, ist die von Nick Tune erfundene Bounded Context Design Canvas. Die ist auch auf dem DDD Crew GitHub vertreten, und wir haben das jetzt inzwischen in Richtung Version weiterentwickelt. Eine der großen Änderungen von Version war, dass wir dort ein Feld von Description auf Purpose umbenannt hatten. Das heißt, wie heißt der Bounded Context und welchen fachlichen Zweck erfüllt er? Dass man da quasi eine sehr starke Parallele einerseits natürlich zu Publikationen von Eric Evans oder Vaughn Vernon oder Vlad oder ähnlichen hat, aber auch im Hinblick auf dieses Kohäsionsthema, dass man das betonen kann. Kleiner Tipp am Rande: Wenn ihr mit dieser Canvas arbeitet – was ich auch bei meinen Kunden ständig tue, ich habe jetzt beispielsweise diese Woche in Berlin drei Tage Domain Modeling mit einem Kunden gemacht, Event Storming, Domains geschnitten und so weiter – da haben wir auch ganz stark mit dieser Bounded Context Canvas gearbeitet. Wenn ihr da einen fachlichen Zweck in dieses Purpose-Feld reinschreibt, geht her und steckt den in Richtung Gemini, ChatGPT oder ähnlichen und fragt, inwiefern dieser fachliche Zweck auf eine funktionale Kohäsion hindeutet. Die LLMs können euch das sehr schön herausfordern. Da habe ich schon die ein oder andere Konversation mit einem Large Language Model gehabt, die wirklich aufschlussreich war, und das war eigentlich eine sehr spannende Unterstützung. Also jetzt nicht: ‘Liebe AI, bau mir das’, sondern ich nutze die AI als Co-Intelligenz, um einfach Sachen zu hinterfragen, aus einer anderen Perspektive betrachten zu lassen. War eine ziemlich spannende Übung, muss ich sagen.

Sven Johann: Fällt mir natürlich gerade ein, auch noch eine Buchempfehlung: Co-Intelligence, von.

Michael Plöd: Das ist super.

Sven Johann: Ich weiß gar nicht, wie er heißt, ich habe den Namen vergessen.

Michael Plöd: Ethan Mollick.

Sven Johann: Ethan Mollick. Ja, Ethan Mollick.

Michael Plöd: Ich habe das auch daheim liegen, das ist super, das ist ein tolles Buch.

Sven Johann: Ja, finde ich auch gut. Ich denke da immer dran: Immer wenn ich mich über AI ärgere, denke ich, denk an Ethan, der sagt, für manche Sachen ist es gut und für manche Sachen nicht so.

Michael Plöd: Ich habe da nachgeschaut: Ethan Mollick.

Sven Johann: Absolute Empfehlung, richtig cool.

Michael Plöd: Alright.

Sven Johann: Ich gucke gerade auf die Uhr. Wir kommen so langsam zum Ende, vielleicht nur ein paar abschließende Fragen. Ich habe hier noch ein paar stehen, da kommen wir nicht mehr dazu, zum Beispiel Messen, Metriken, so etwas wie Elcom, aber lassen wir das.

Michael Plöd: Nee, lass uns da mal ganz kurz drüber reden. Lass uns die Zeit mal nehmen, ja? Und da ist mir eine Sache ganz wichtig: Ihr müsst Metriken – es gibt verschiedenste Metriken, mit denen man Kohäsion messen kann. Da gibt es Tonnenweise Dinge. Ihr müsst allerdings schauen, dass die Metriken, die ihr wählt, zu eurem Technologie-Stack passen. Also, schönes Beispiel: LCOM. LCOM steht für Lack of Cohesion in Methods, und da gibt es verschiedenste Versionen davon, eins bis vier. Aber generell geht es darum, dass sie zählen, wie viele Methoden Instanzvariablen einer Klasse gemeinsam nutzen. Arbeitet ihr jetzt beispielsweise mit einer Spring Java Application und wollt von irgendwelchen Spring Beans oder Spring Klassen, von Spring verwalteten Klassen, Kohäsion messen, und ihr arbeitet in einem Multithreading-System, was ja meistens bei so Web-Applikationen der Fall ist? Dann solltet ihr wissen, dass Spring aus diesen Klassen Singletons macht. Das heißt, es gibt nur eine Instanz, und da arbeitet niemand mit Instanzvariablen, weil wir hätten ja natürlich Race Conditions, Multithreading-Probleme etc. Das heißt, die Metrik sagt euch, ihr habt keine hohe Kohäsion, weil sie nicht zu eurem Technologie-Stack passt. Also, da müsst ihr ein bisschen aufpassen, und das ist so ein Hinweis. Da gibt es ganz viel; ihr müsst halt das zu eurem Technologie-Stack oder das, was ihr verwendet, an der Stelle passend auswählen. Wenn ihr jetzt natürlich mit einem astreinen Domain Model arbeitet, in so einer Onion Architecture oder hexagonalen Architektur, dann will ich da drin kein Spring haben, dann habt ihr das Problem an der Stelle nicht. Aber passt da bitte ein bisschen auf, dass ihr die passenden Metriken wählt zu eurer Architektur, weil sonst fliegen euch die an. Das ist das, was ich sagen wollte, das ist, glaube ich, ganz wichtig.

Sven Johann: Okay. Ja, okay, lassen wir es. Also, ich könnte noch in dieses Rabbit Hole weiter reingehen, neulich noch interessante Erfahrung mit der Mathematiker.

Michael Plöd: Ja, ich glaube, in einem eigenen Podcast.

Sven Johann: Ja. Was sagt denn, also jetzt haben wir gesagt, okay, Domain Driven Design bis zum Boden sozusagen. Was sagt denn Larry Constantine und Co? Haben die auch irgendwie Empfehlungen gemacht, wie man dahin kommt? Ich meine, war ja sozusagen Jahre vor DDD, wobei ich weiß, DDD ist eigentlich, die Ideen gibt es schon länger, ja? Aber was sagt Larry Constantine?

Michael Plöd: Also, in dem SMC Paper haben sie ja ganz stark geschrieben, dass das eine nützliche Technik ist, um rauszufinden, ob ein Modul funktional gebunden ist, quasi eben dieses Arbeiten mit dem Zweck ist. Das ist eigentlich so der Kerntreiber aus diesem Structure Design. Also, versucht mal den Zweck zu beschreiben, analysiert den Satz, und die haben in dem Paper auch Heuristiken publiziert, wie ihr einen Satz analysieren könnt, auf welche Form von Kohäsion der hinweist. Also, das ist das, was halt da drin stand, jetzt auf der methodischen Ebene. Da muss man natürlich sagen, da hat sich die Welt natürlich schon wahnsinnig weiterentwickelt, gerade auch auf der methodischen Ebene. Und das ist ja auch ehrlich gesagt im DDD-Umfeld, wenn man mal anschaut, vor Jahren, wo das Buch von Eric Evans rauskam, da waren halt noch so Hinweise drin: Ihr müsst aktives Zuhören praktizieren, ihr müsst Fragen stellen, die zu neuen Erkenntnissen führen können. Und dann haben sich sehr viele Leute gefragt: Ja, wie mache ich denn das? Und dann wurden halt später Methodiken entwickelt, wie Domain Storytelling, Event Storming, Event Modeling, was weiß der Geier was. Und diese ganze Disziplin des Collaborative Modeling entstand ja dann erst. Und auch da, das ist eigentlich eine kontinuierliche methodische Evolution, die da stattfindet.

Sven Johann: Alright. Dann machen wir auf jeden Fall noch mal einen Podcast über Metriken.

Michael Plöd: Ich weiß ja nicht, ob ich da die beste Person dafür bin.

Sven Johann: Nee, also ich denke, ja, ich wollte nur sagen, ich habe hier noch so ein paar Punkte, aber ich denke, wir haben eigentlich schon relativ viel diskutiert. Also, ich habe auf jeden Fall genügend Antworten für mich bekommen und weiß ja, ‘guaranteed audience of one’ bedeutet ja immer, wenn es für mich interessant ist, ist es hoffentlich auch für andere interessant. Vielleicht mal so eine abschließende Frage: Dein Vortrag, wann kann man den denn noch mal sehen live und in Farbe?

Michael Plöd: Ach, zum Thema Kohäsion ist aktuell, glaube ich, nichts angekündigt Konferenz-mäßig. Schauen wir mal.

Sven Johann: Gibt es den auf Video?

Michael Plöd: Ich glaube, der müsste inzwischen irgendwo auf YouTube sein.

Sven Johann: Ja, ja, weil ich habe den tatsächlich nie gesehen.

Michael Plöd: Ich bin mir aber nicht ganz sicher, aber ich sage mal, wenn jemand Bock hat, den auf ein Meetup zu bringen oder auf einer Konferenz zu haben, ihr könnt euch natürlich gern melden. Ich rede gern über das Thema, und zuletzt habe ich ihn als Keynote am Software Architecture Summit in München gehabt.

Sven Johann: Okay.

Michael Plöd: Das war vor eineinhalb, zwei Monaten, eineinhalb Monaten, glaube ich, war es circa.

Sven Johann: Okay.

Michael Plöd: Ich würde gerne noch eine Sache sagen an der Stelle.Achtet darauf, wie ihr das Thema Kohäsion betrachtet. Ich glaube, Kohäsion ist eine Frage verschiedenster Perspektiven, und wenn ihr diese Modellierungsaufgaben macht und modelliert in einer hochkohäsiven Gruppe von Leuten mit hochkohäsiven Perspektiven, mit hochkohäsiven Vorurteilen, Biases, hochkohäsiven Verhaltensweisen und hochkohäsiven Einstellungen, kann es gut sein, dass ihr vielleicht an dem Kern der funktionalen Kohäsion aus einer ganzheitlichen Perspektive vorbeigeht. Also, redet mit unterschiedlichen Stakeholderinnen und Stakeholdern in eurer Organisation über das Thema. Redet mit der Fachseite, redet mit der UX-Seite, redet mit vielleicht den Endanwenderinnen und Endanwendern etc., weil die können vielleicht eine andere Perspektive auf das Thema funktionale Kohäsion haben. Und wenn ihr da nur in eurem eigenen Sipline kommt, lauft ihr Gefahr, vielleicht eine sehr einseitige Betrachtungsweise darauf zu bekommen. Also, bitte arbeitet kollaborativ an der Sache. Und das ist jetzt nicht nur ein IT-Thema und nicht nur ein Software-Architektur-Thema. Natürlich geht es auch darum, aber was hat Alberto Brandolini immer gerne gesagt, und ich will Alberto zitieren: Was geht am Ende des Tages in Produktion? Ist es das Fachwissen und die Perspektive der Personen auf der Fachseite, der Domain Experts etc., oder ist es die Menge der Annahmen über dieses Wissen, das in den Köpfen der Entwicklerinnen und Entwickler ist? Letzteres geht produktiv, und schaut bitte, dass ihr das möglichst verkleinert. Und ich glaube, dann bekommt man eine spannende Perspektive auf das Thema Kohäsion.

Sven Johann: Ja, jetzt muss ich doch noch mal fragen, weil ich bin ja so ein alter Stakeholder-Analyst, Erwartungen an Stakeholdern, von Stakeholdern klären und so weiter. Ich tue mir damit offensichtlich ziemlich leicht, weil oft gemacht. Aber jetzt im Sinne von Kohäsion, was muss ich tun, um diese Sicht irgendwie zu bekommen?

Michael Plöd: Modelliert gemeinsam. Modelliert zusammen. Also, ich sage immer wieder, Boundary-Kontextgrenzen beispielsweise aus der DDD-Welt, das modelliere ich immer zusammen mit der Fachseite.

Sven Johann: Also Fachseite mit dabei sind, ja, und Domain Experts und genau, verschiedenste Perspektiven abholen an der Stelle. Ja, ja, also Fachseite, weil du auch gesagt hast, UX und User und so weiter. Also, ich meine, Fachseite kein Problem, aber dann denke ich mir so, ja, gibt ja auch Stakeholder wie Security oder Chief Digital Officer oder so, die werden sich wahrscheinlich nicht einladen.

Michael Plöd: Ich weiß nicht, wer das gesagt hat, aber irgendwo habe ich das mal aufgefangen: Ihr müsst in solchen Tätigkeiten Leute haben mit Fragen und Leute mit Antworten, ja, das wäre ein bestimmter Themenbereich. Und ich würde halt situativ entscheiden, wer da die spannenden Leute sind, aber am Anfang beginne ich erst einmal damit, sehr viele Perspektiven auf einer sehr breiten Ebene quasi einzufangen. Und dann kann man ja destillieren, dass man sagt: Hey, danke für die Perspektive, aber wir gehen jetzt mal in der Richtung weiter, und wenn wir Fragen haben, kommen wir noch mal auf dich zu. Sehr häufig merken die Leute das selber schon dann und sagen: Ich weiß nicht, was ich da für einen Mehrwert jetzt aktuell liefere. Keine Ahnung, kann mich vielleicht auf Standby setzen oder irgendwie sowas. Genau. Das funktioniert eigentlich in der Regel ganz gut.

Sven Johann: Alright. Übrigens, also ich habe den Spruch von Dan North gehört, aber der hat wahrscheinlich irgendwo geklaut.

Michael Plöd: Kann sein. Ja, Dan North ist ja auch ein, oder Dan Terros North, ist ja auch ein wandelnder, eine wandelnde Zitatesammlung.

Sven Johann: Genau, genau. Alright, ich bedanke mich auf jeden Fall. War ziemlich spannend. Alle Links werden wir auf jeden Fall hier in die Shownotes packen. Und ich werde trotzdem das Paper, glaube ich, von Larry Constantine mir noch mal reinziehen.

Michael Plöd: Stevens, Myers, Constantine. Ja, ist jetzt spannend zum Lesen. Auf jeden Fall.

Sven Johann: Ja, also warum sage ich trotzdem, weil du gesagt hast, na ja, ein paar Sachen sind ein bisschen Oldschool, aber lohnt sich wahrscheinlich trotzdem, wie du sagst.

Michael Plöd: Auf jeden Fall. Also, ich sage, da stehen jetzt keine falschen Sachen drin, auf gar keinen Fall, und das ist mal ganz interessant, wo eigentlich viele dieser Ideen auch herkommen, dass man diese Perspektive mitbekommt. Ich bin jetzt nicht so dieser Fuchs, der jede Woche ein Paper studiert oder so, aber ab und an ziehe ich mal sowas raus und lese es durch und befasse mich damit. Das ist hier und da eigentlich schon eine ganz spannende Übung.

Sven Johann: Ja. Also, warum ich immer, dann höre ich wirklich auf. Warum ich immer Constantine zitiere, ist, weil James Coplien immer geschwärmt hat von Larry Constantine, und die anderen Namen, die sagen mir nichts, aber Constantine kann ich mir deswegen ganz gut behalten.

Michael Plöd: Na dann.

Sven Johann: Alright, dann vielen Dank und vor allen Dingen an die Zuhörer noch vielen Dank, dass ihr es soweit geschafft habt mit dem Zuhören. Ciao ciao.

Michael Plöd: Und auch an die Zuhörerinnen. Vielen Dank.