Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Hintergrund
Hintergrund ist, dass ich eine Präsentation dazu habe, wie man gerade sieht.
Ursprung der Präsentation
Und diese Präsentation habe ich tatsächlich auch schon auf verschiedenen Konferenzen gehalten.
Aber als ich die Präsentation vorbereitet habe, habe ich so viele Folien produziert, dass das in einen typischen Konferenzslot nicht reinpasst.
Und habe das dann gekürzt, um es in einen Konferenzslot reinzubekommen.
Und habe mir gedacht, naja, das könnte ich irgendwann auch mal vollständig präsentieren.
Das ist genau das, was ich hier mache.
Aufteilung des Inhalts
Ich habe das aufgeteilt.
Also meine Erwartungshaltung ist, dass ich heute sozusagen nicht alles schaffe.
Aber schauen wir mal.
Das heißt, heute wird es vor allem um strategische Geschichten gehen.
Und dann beim nächsten Mal, ich denke, das sollte der Freitag sein, wird es dann halt um das Thema gehen, wie man tatsächlich so taktische Geschichten eher umsetzt.
Fragen jederzeit gerne willkommen.
Also wir haben tatsächlich, glaube ich, eine ganze Menge an Zeit, uns mit Fragen zu beschäftigen.
Ja, und von daher würde ich sagen, fangen wir einfach mal an.
Warum dieser Talk?
Also Domain-Domain-Design hat eben eine ganze Menge an wertvollen Werkzeugen.
Und die Frage ist jetzt, welche davon sind jetzt tatsächlich wirklich sinnvoll und notwendig?
Wie kann ich die alle kombinieren?
Und gleich am Anfang sozusagen Hinweis.
Das Ganze sieht möglicherweise ein bisschen aus wie so ein Wasserfall.
Das heißt, wir reden halt irgendwie darüber, wie wir halt vorgehen.
Und dabei müssen wir halt irgendeine Reihenfolge von den verschiedenen Ansätzen halt haben.
Aber tatsächlich geht es hier um verschiedene Ebenen von Abstraktion.
Das heißt, wir arbeiten uns von sehr abstrakten Dingen weiter voran, bis hin zu dem halt konkreteren Ebenen.
Und das bedeutet, wir sollten halt eben gerade nicht wasserfallmäßig vorgehen.
Dazu gibt es auch diverse E-Personen, die irgendwie sagen, dass das keine gute Idee ist, sondern wir sollten halt in Iterationen vorgehen.
Und wir sollten halt irgendwie diese Ebene der Abstraktionsebene ändern.
Das heißt also, diese Techniken, die wir hier diskutieren, führen irgendwie zu Feedback auf unterschiedlichen Ebenen.
Und abhängig davon, auf welcher Ebene ich Feedback und Dinge halt irgendwie erfahren will, wende ich irgendeine von diesen Techniken an.
Das bedeutet nicht, dass die in dieser Reihenfolge zu nutzen sind, sondern es geht irgendwie darum, dass man die sozusagen an den richtigen Stellen einsetzt, um die richtigen Ideen, das richtige Feedback zu bekommen.
Gut, der Frage zweierlei It Depends hat gesagt, Eberhard, du hattest mal von Wernum eingeleitet, genau diese Folge zum Thema Ports and Adapters und DDD.
Dazu würde ich gerne meine Frage nach dem Zusammenhang dazu stellen.
Ja, mein Plan ist es, dieses Thema, also Ports and Adapters, beziehungsweise hexagonale Architektur zu diskutieren, und zwar bei der nächsten Episode.
Und tatsächlich ist die Frage nach dem Zusammenhang eine gute.
Also ob irgendwie Domain-Domain-Design mit diesem Thema zusammenhängt.
Gut, also da nicht, schreitet auch das nächste Mal wieder ein.
Da würde ich das Thema dann darüber diskutieren.
Gut, das dazu.
Fangen wir an mit dem Thema Event-Storming.
Und jetzt ist halt die Frage, warum wollen wir eigentlich Event-Storming machen?
Wir haben grundsätzlich folgendes Problem.
Wir haben auf der einen Seite Menschen, die Domain-Expertinnen sind, und auf der anderen Seite haben wir Software-EntwicklerInnen.
Und Domain-Expertinnen verstehen per Definition die Domäne, und Software-EntwicklerInnen verstehen das Wissen, also wissen, wie man aus Wissen Software generiert, das also so strukturiert, dass am Ende Software dabei rauskommt.
Und das bedeutet, dass wir jetzt zwei Rollen haben, die irgendwie zusammenarbeiten müssen.
Also nicht Domain-Domain-Design bedeutet, die Domäne treibt das Design.
Das heißt, Domain-Expertinnen wissen, was eigentlich das Design treibt.
Aber Menschen wie ich, Software-EntwicklerInnen, ArchitektInnen und solche Leute, die müssen halt irgendwie verstehen, wie man jetzt dieses Wissen so strukturiert, oder müssen halt dieses Wissen haben, zur Verfügung haben, um es dann eben so zu strukturieren, dass letztendlich Software daraus wird.
Und das führt jetzt dazu, dass wir hier irgendwie kollaborieren müssen.
Denn anders geht es nicht.
Also Domain-Expertinnen kennen keine formalen Methoden.
Software-EntwicklerInnen verstehen die Domäne nicht.
Das heißt also, wir können unmöglich jetzt irgendwie sagen, okay, irgendwie wird die eine Rolle die Skills der anderen Rolle lernen und dann das sozusagen im Alleingang machen.
Also es muss eine Kollaboration geben, um eben gemeinsam dieses Modell zu erstellen.
Und dafür bietet sich halt Event-Storming an.
Grundlagen des Event Stormings
Event-Storming ist ein relativer Low-Tech-Ansatz.
Das heißt, die Verwendung eines Events ist etwas, was in der Vergangenheit passiert ist.
Deswegen verwende ich eben zumindest ein Hauptwort, also ein Substantiv und einen Verb.
Und zwar in der Vergangenheit, ich schreibe das halt irgendwie auf einen Orangen Sticky.
Das heißt, ich habe hier zum Beispiel sowas wie Bestellung akzeptiert.
Das steht jetzt auf einem Orangen Sticky.
Und damit habe ich jetzt eben mein Event.
Die Farben, die Farbcodierung ist etwas, worauf die Menschen bei Event-Storming Wert legen.
Ich glaube, das ist vielleicht für eine Standardisierung auch gar nicht so schlecht.
Und das ist so ein bisschen die Idee.
Vielleicht an der Stelle ein Hinweis zu dem Talk an sich.
Mein Ziel ist es jetzt nicht, eine komplizierte Domäne darzustellen.
Sondern meine Intention ist es, zu sagen, so funktionieren diese Techniken, so greifen sie ineinander.
Was bedeutet, dass ich jetzt eine sehr triviale Modellierung mir nur ausgewählt habe.
Also nichts, was super kompliziert ist.
Und das bedeutet eben, dass wir da eben zwar ein vollständiges Beispiel haben mit allen Techniken.
Aber sicherlich kann es was halt sozusagen der typischen Domänenkomplexität gerecht wird.
So Strudelhund69 hat auf Twitch gesagt, vielen lieben Dank für die ganzen Videos.
Höre ich immer wieder rein.
Freut mich sehr.
Und tatsächlich ist das Feedback, was auch sonst von euch an mir kommt, das positive Feedback für uns total wichtig.
Und halt ein wichtiger Motivator.
Von daher, genau sowas ist halt super.
Vielen Dank dafür.
Gut, also das ist Eventstorming.
Ich schreibe also solche Events auf.
Vorgehensweise
Und die erste Phase, in der ich das mache, ist Chaotic Exploration.
Das heißt, ich sage im Prinzip, baut so viele Events, wie es irgendwie geht.
Und lasse den Leuten das halt, dann gibt ihnen halt sozusagen freie Bahn, dafür zu sorgen, dass sie das halt irgendwie umsetzen.
Und dann kommt als nächstes, also logischerweise laufen hier die Events von links nach rechts.
Das kann man sich, glaube ich, irgendwie vorstellen.
Und wenn ich aber Chaotic Exploration mache, bedeutet das, dass das jetzt nicht überall wirklich umgesetzt ist.
Also links sind die Events, die ja die Vorbedingungen sind für die rechten Events.
Und das heißt, was ich jetzt machen kann, ist die Timeline entforcen.
Ich sorge also dafür, dass die Events, die halt vorher irgendwie vielleicht so angeordnet sind, danach irgendwie so angeordnet sind, dass sie eben dann tatsächlich auch linear vernünftig angeordnet sind.
Und das mache ich, indem ich eben nochmal durch diese Zeit, durch die Timeline durchgehe.
Also festlege, dass tatsächlich die Events links von den Events rechts sind.
Das kann ich auch so umgekehrt machen.
Ich kann sagen, okay, hier ist irgendein Event.
Sind die Vorbedingungen eigentlich dafür alle da?
Ja, dann ist sehr gut.
Sonst strukturiert die Events so, dass das eben tatsächlich auch dann in dieser Reihenfolge da ist.
Dann kann ich als nächstes Swimlanes identifizieren.
Das sind so parallele Prozesse, die halt irgendwie parallel passieren.
Und ich kann jetzt hier in dem Beispiel zum Beispiel sagen, okay, hier ist eine Swimlane und das ist irgendwie die Swimlane, wo ich eine Rechnung schreibe.
Also das ist ja ein E-Commerce System.
Hier ist die Swimlane, wo ich halt irgendwie jetzt etwas ausliefere.
Und das sind ja mehr oder minder parallele Aktivitäten.
Da gibt es Berührungspunkte.
Ich muss halt dafür sorgen, dass halt eine Rechnung geschrieben wird, wenn tatsächlich die Sachen ausgeliefert worden sind und umgekehrt.
Aber im Wesentlichen sind dann halt die konkreten Schritte tatsächlich Dinge, die im Wesentlichen parallel laufen.
Und dann gibt es so Pivotal Events.
Das sind so Events, nach denen die Welt irgendwie anders ist.
Da gibt es eine Menge an Heuristiken.
Zum Beispiel Bestellung akzeptiert ist zu einer Vorbestellung.
Akzeptiert ist es halt relativ easy zu sagen, okay, ich packe noch irgendwas dazu.
Da habe ich halt irgendwie den Einkaufswagen.
Danach ist das schwierig.
Also eigentlich wird es dann eben tatsächlich schon verschickt.
Ich kann es vielleicht nur noch gesamt stornieren.
Das heißt also, die Welt ist anders und es gibt, weil es eben schwieriger ist, Dinge jetzt nicht mehr zu bestellen.
Und es ist außerdem so, dass es neue Objekte gibt.
Also es gibt zum Beispiel die Rechnung, es gibt die Lieferung und so weiter und so weiter.
Das heißt also, dass ich dort dann tatsächlich eine andere Welt habe.
Hier ist zum Beispiel noch sowas.
Also das Paket ist jetzt aus meinem Lager raus.
Das bedeutet, dass ich jetzt irgendwie nicht mehr sagen kann, okay, ich schicke es nicht mehr raus.
Sondern es ist jetzt irgendwie in der Verantwortung von DHL.
Was irgendwie zum Beispiel bedeutet, dass wenn es halt verloren geht, das halt deren Problem ist.
Und das ist vielleicht eben auch etwas, wo halt die Welt dann etwas anders aussieht.
Und das ist jetzt ein Pivotal Event.
Würde Order Accepted eher eindeutig für ein Pivotal Event halten, weil es halt wirklich sehr fundamental ist.
Pivotal ist eben irgendwie eine fundamentale Änderung.
Dass das Paket jetzt das Lager verlassen hat, ist vielleicht etwas weniger Pivotal sozusagen.
Also das ist vielleicht etwas weniger eindeutig.
So Vorteile davon.
Das ist relativ low-tech.
Das heißt, es ist einfach, das für Domänenexpertinnen zu verstehen.
Also ich schreibe halt ein Event auf eine Karte, mache irgendwas, was sich halt interessiert.
Das sollte man typischerweise eben bekommen.
Menschen können parallel an diesem Ding arbeiten.
Weil ich habe halt eine Wand.
Da sind halt diese ganzen Dinge halt irgendwie dran.
Und das ist sehr easy, da halt mit vielen, vielen Menschen parallel zu arbeiten.
Was halt sonst vielleicht irgendwie nicht so einfach ist.
Und das ist, glaube ich, eine von den nicht offensichtlichen Dingen, die aber tatsächlich sehr wichtig sind.
Die sozialen Strukturen werden offensichtlich.
Was ich damit meine ist, ich sehe, wer arbeitet mit wem zusammen.
Wer versteht Dinge.
Wer sind Expertinnen für bestimmte Dinge.
Und das ist, glaube ich, auch ein wichtiger Hinweis.
Das heißt, ich habe dort so eine Art Labor, in dem jetzt irgendwie alle Menschen, die an diesem ganzen Ding arbeiten sollen, TechnikerInnen, Domänexpertinnen und so weiter, mal zeigen können, wie sie das eben tatsächlich tun.
Und dadurch werden eben eine Menge Sachen offensichtlich.
Herausforderungen, die richtigen Menschen irgendwie in den Raum zu bekommen.
Domänexperte ist so ein bisschen ein schwieriger Begriff.
Da gibt es halt zum einen die Menschen, die jeden Tag das System benutzen.
Die wissen halt, wie das System tatsächlich funktioniert.
Dann gibt es irgendwie Menschen, die sagen, okay, warum investieren wir jetzt?
Warum bauen wir da irgendetwas?
Das sind Menschen, die so ein bisschen eine Vision haben.
Und das wir auf dieser Ebene diskutieren können.
Und ich brauche beide.
Und ich brauche idealerweise eigentlich so Leute, die tatsächlich vielleicht noch fachlich mit dem System arbeiten, aber halt eine weitergehende Vision haben.
Also mir nützt Leute, die nur sagen, so funktioniert jetzt das System, helfen mir nicht dabei, das System weiterzuentwickeln.
Deswegen brauche ich da halt irgendwie eine Kombination.
Sprich, Leute, die es wirklich benutzen, haben vielleicht irgendwie nicht die Vision und den Kontext.
Manager haben vielleicht irgendwie nicht dieses Verständnis darüber, wie es in der täglichen Arbeit funktioniert.
Und jede Person, die daran beteiligt ist, versteht eben nur einen Teil dieser Logik.
Und die muss ich jetzt irgendwie alle zusammenbekommen.
Ergebnis davon im gemeinsamen Verständnis der Domäne und damit eben ein Modell der Domäne, das ich aber erstmal ändern muss und anpassen muss, bevor ich es implementieren kann.
Das heißt also, ich habe eigentlich dadurch nur in Anführungsstrichen die Möglichkeit, erstmal dieses gemeinsame Verständnis auf die Reihe zu bekommen.
Und hier steht noch, wie gesagt, die Rollen und die Kollaboration wird irgendwie offensichtlich.
Dann lass mich kurz schauen.
Achso, genau.
Ich bringe das, glaube ich, kurz noch mal zu Ende.
Da sind jetzt ein paar Fragen aufgelaufen.
Ich glaube, das bringe ich dann tatsächlich kurz noch mal zu Ende.
Also Alternativen dazu.
Domain Storytelling, das ist sehr prozessorientiert.
Aber auch etwas, wo ich eben kollaborativ Dinge sozusagen hinschreibe und hinmale und da gemeinsam daran arbeite.
Und sowas wie Context Mapping, wo ich halt Kontexte einfach aufmale und halt sage, okay, das sind eben die Kontexte, die ich hier sehe.
Und das sind die Funktionalitäten der Kontexte.
Wem das interessiert?
Es gibt eine Episode zum Thema Domain Storytelling mit dem Stefan und dem Henning, die darüber auch das Buch geschrieben haben und das auch so ein bisschen erfunden haben.
Da kann man sich also Domain Storytelling angucken.
Es gibt diese Episode, wir bauen eine Software-Architektur.
Da zeige ich, wie ich so Kontext Mapping machen kann.
Also wie ich einfach Dinge zusammenpacke, die halt irgendwie eine gemeinsame Funktionalität haben.
Und es gibt die Episode zum Thema eine Architektur entwerfen, am Beispiel der ISA-KoB-Beispielaufgabe.
Und da diskutiere ich tatsächlich dann eben, wie man Kontext Mapping macht anhand der Architektur-Beispielaufgabe.
So, jetzt lasse ich mich kurz auf die Dinge aus dem Chit eingehen.
Und ich blende dafür, glaube ich, mal kurz die Folien aus.
Frage, jetzt Feierlei Etipenz hat geschrieben, das Modell eben zwischen den Köpfen, ist das dein Domain-Modell?
Und vielleicht kannst du kurz sagen, was da natürlich zwischen Domäne und Domänen-Modell ist.
Meiner Meinung nach wichtig.
Also ein Modell ist für mich eine mehr oder minder formalisierte, ein mehr oder minder formalisiertes Erfassen von dem, was da draußen eigentlich passiert.
Und wir haben hier jetzt so ein Modell.
Also wir haben halt diese Events, und die zeigen ja, was da draußen passiert.
Code ist ein weiteres Modell auf einer konkreteren Abstraktionsebene.
Da ist es eben so, dass ich tatsächlich eben dann diese Business-Prozesse so umgesetzt habe, dass ich sie eben in einem IT-System laufen lassen kann.
Hier habe ich ja nur ein gemeinsames Verständnis durch irgendwelche Events.
Das sind irgendwie Modelle, also Dinge, die mir was über die Realität sagen, sodass ich darüber halt reflektieren kann.
Und diese gemeinsame Entwicklung der Modelle ist eigentlich die Kernaufgabe von Software-Entwicklungen.
Das Modell, um das es da insbesondere geht, ist eben natürlich der Code.
Aber die anderen Modelle, wie zum Beispiel die bei Events-Domain, oder bei Storytelling oder so, oder eben bei Context-Mapping, sind halt irgendwie auch spannend, weil sie Voraussetzung dafür sind, dass wir solche Modelle im F3 bekommen.
Jan hat geschrieben, das Arbeiten mit Karten wünsche ich dir auch keine große Tool-Unterstützung, mit so einem Zwinker-Smiley.
Genau, das ist eins der Feature, und vielleicht an der Stelle, Miro ist halt auch irgendwie dein Freund, das heißt also, wenn man das hat, oder Concept-Board, oder was da irgendwie rumfliegt, Mural, das heißt also, man kann diese Sachen eben auch tatsächlich mit Tool-Unterstützung remote irgendwie machen.
Und das ist auch eine Sache, die, glaube ich, sinnvoll ist.
Also ich mag mittlerweile die digitalen Tools eigentlich lieber als die Post-its, denn mit den digitalen Tools habe ich eben automatisch gleich das Zeug irgendwo archivierbar, und ich kann das relativ leicht kopieren und wieder aufgreifen und so weiter und so weiter.
Und ich kann es eben remote gemeinsam ändern.
Also mittlerweile bin ich halt der Meinung, das ist vielleicht besser.
War das Ergebnis nicht sogar etwas zum Wegwerfen?
Es soll Know-how geteilt werden und kann ein Artefakt erstellt werden?
Ja, das ist ein guter Punkt.
So kann ich das aufgreifen.
Ich wäre da nicht so orthodox und würde halt sagen, ich schmeiße das Artefakt weg.
Aber die Idee zu sagen, es geht vielleicht gar nicht um das Artefakt, sondern es geht darum, dass wir halt diesen Prozess haben und Wissen austauschen, und eben auch insbesondere darum zu beobachten, wie dieses Artefakt entsteht.
Das stimmt, das ist ein guter Punkt an der Stelle.
Der Nafetz Nesniv hat geschrieben, LOL-Manager haben keine Ahnung.
ZfenkaSmiley finde ich schwierig.
Die müssten mindestens dazu in der Lage sein zu sagen, warum wir jetzt gerade diese große Menge Geld ausgeben, um irgendwie ein neues Stück Software zu implementieren.
Und mindestens auf der Ebene sollten die was sagen können.
Ich finde es bei Event-Storming wichtig, dass eben tatsächlich alle beteiligten Gruppen prinzipiell daran teilnehmen können.
Und ich würde da halt niemanden ausschließen.
Also wie gesagt, so eine Vision, die irgendwie sagt, warum wollen wir das eigentlich besser machen?
Aus der Management-Perspektive kann das sehr wertvoll sein.
Philipp Sporrer sagt, sollte man immer den gesamten Business-Prozess im Event-Storming abhandeln, oder kann man auch Teilbereiche sinnvoller arbeiten?
Also wie soll ich sagen, das ist ein guter Punkt, weil wir über eine Menge an Techniken diskutieren.
Und ich würde sagen, eine Technik soll ein Problem lösen.
Und was auch immer dein Problem ist, wenn du denkst, dass die Technik dafür helfen kann, dann nutze sie halt.
Sprich, Event-Storming für einen Teilprozess ist aus meiner Sicht völlig fein.
Wenn das System groß genug ist, werde ich mir wahrscheinlich in mehreren Sessions unterschiedliche Menschen dazuholen, um halt unterschiedliche Teilbereiche zu untersuchen.
Und das ist eben ein Ergebnis der Komplexität.
Mark M. schreibt, es gibt Ruth Malan, die sich sehr mit System-Design und Contextual Design beschäftigt, Domain Driven Design, ein vorstehendes Beispiel, ist bestimmt auch mit Systems-Thinkings verknüpft, ja oder nein?
Das ist ein bisschen das, was ich hier ja sage.
Also mit Systems-Thinking versuche ich eben auch, zum Beispiel die soziale Komponente mehr anzuschauen.
Und das kriege ich halt mit Event-Storming hin, weil ich hier sehe, wie die Menschen halt zusammenarbeiten.
Ach so, genau, Frage 2.
Hast du aus deiner Workshops gute Erfahrungen mit teilweise asynchronen Formaten gemacht?
Ich bin nicht sicher, was mit asynchronen Formaten gemeint ist.
Also ich würde versuchen, diese Dinge, über die wir jetzt reden, wie zum Beispiel Event-Storming, synchron zu machen, weil ich sonst Schwierigkeiten mehr erlebe.
Ich glaube, wenn man halt alle virtuell zumindest in einem gemeinsamen Raum hat und daran arbeiten lässt, ist es wahrscheinlich deutlich produktiver.
Also da hätte ich echt, also ich habe zum einen sowas asynchron noch nie gemacht, zum anderen glaube ich, würde ich davon halt irgendwie auch tatsächlich abraten.
Was ist der Zusammenhang zwischen System Thinking und System Design und diesem Video inklusive dem von Lisa?
Lisa hatte ja zwei gemacht, zum einen mit, also da geht es wahrscheinlich um das mit Diana.
Ich glaube, ein wesentlicher Punkt, über den wir halt noch stärker nachdenken müssen, ist eben, dass wir Systeme integriert zwischen sozialen und menschlichen Beziehungen sozusagen sehen müssen.
Und das System ist sozusagen unausweichlich das, was dieses soziale Setting erzeugt hat.
Und das ist halt ein Teil der Erklärung dafür, dass es halt so aussieht, wie es halt aussieht.
Und wie gesagt, mir gefällt halt auch an den Fragen, genau diese Diskussion mit, ist das eigentlich wirklich das Artefakt, was so relevant ist?
Also wir haben hier einen Lernprozess, wir sehen, wie Menschen interagieren.
Das ist vielleicht sogar wichtiger als das Artefakt selber.
Und wir hatten mit der Xing Chao vor einiger Zeit eine Episode, die hat genau das irgendwie auch gesagt.
Und ich finde immer noch, dass das ein sehr spannender und wichtiger Punkt an der Stelle ist.
Gut, genau.
Danke für die Antworten, kommt hier sehr gerne.
Und dann können wir, glaube ich, weitermachen.
Und ich erzähle mal was zu, genau, Bauen im Kontext ist das Nächste.
Also warum eigentlich Bauen im Kontext?
Bounded Contexts
Naja, das ist eine grobgranulare Aufteilung der Domäne.
Und zwar sowas, was ich jetzt einem Team zuweisen kann.
Und ein Team kann irgendwie auch an mehreren Bauen im Kontext arbeiten.
Aber ein Bauen im Kontext sollte halt idealerweise einem Team gehören, wobei man darüber auch diskutieren kann.
Definition
Bauen im Kontext, wieder ein sehr schöner Name.
Bedeutung
Also das sind Grenzen, in denen eben ein Modell existiert.
In diesem Fall ist es Code.
Also so konzeptionell eben die Idee.
Und auf der anderen Seite die Ubiquitous Language.
Also eine gemeinsame Sprache.
Und hier zumindest im Stream ist ja immer mein Standardbeispiel die berühmte Nali, die Nachlieferung.
Und das ist eben etwas, was in einem Bauen im Kontext bekannt ist, eben bei einem bestimmten Kunden.
Und die Idee ist jetzt, dass das ein Teil dieser Ubiquitous Language ist.
Die ist allgegenwärtig, und zwar ist die allgegenwärtig in dem Sinn, dass ich das halt im Code habe.
Dort hätte ich jetzt also eine klasse Nachlieferung oder Nali.
Wenn wir in der Datenbank, hätte ich vielleicht eine Tabelle dazu.
Und das wäre jetzt auch etwas, was hat Software-Entwickler und Domäne-Experten beim täglichen Gespräch benötigen.
Und dadurch komme ich eben in diese Kommunikation.
Ich habe eine vereinfachte Kommunikation.
Ich kann mich also jetzt eben hinstellen und sagen, okay, die Nachlieferung.
Und dann kann ich das, also nicht, dass wir halt hier, das heißt Domäne-Experten sagen, wir liefern Dinge nach, wenn folgende Bedingungen erfüllt sind.
Und ich kann jetzt, wenn wir als Techniker mich hinstellen, kann ich sagen, okay, alles klar.
Das heißt, es gibt eine klasse Nachlieferung, da schreibe ich es halt rein.
Und dadurch ist die Übersetzung einfacher.
Das wäre schwieriger, wenn da halt irgendwie eine Delivery wäre oder eine Post-Delivery oder was auch immer man sich da halt überlegen könnte.
Sondern ich will eben genau diese Nachlieferung da irgendwie drin haben.
Das führt dazu, wenn ich mir jetzt zum Beispiel den Rechnungserhöhungsprozess und den Lieferprozess angucke, dass ich dort bestimmte Informationen haben möchte.
Also zum Beispiel beim Rechnungserhöhungsprozess den Kunden, der hat die Rechnung bezahlt.
Und beim Lieferprozess der Kunde, zu dem die Produkte hingeschickt werden.
Und das sind potenziell zwei unterschiedliche.
Also wenn ich jetzt auf Kosten von Swag Lab ein Laptop bestelle, dann ist Swag Lab die Firma, die die Rechnung bezahlt.
Und ich bin derjenige, wo es hingeliefert werden soll.
Swag Lab in Hamburg, ich in Kaiserslautern.
Und ich bin irgendwie ungehalten, wenn das halt irgendwie verwechselt wird.
Klassisches Beispiel auch der Hotelcheck-In.
Beim Hotelcheck-In ist es mittlerweile so, dass ich irgendwie sage, ich bin der Ebert Wolf und ich wohne in der Swag Lab GmbH, Simon von Utrechtstraße in Hamburg.
Weil ich möchte halt am Ende gerne die Rechnung haben.
Und das ist irgendwie schwierig.
Deswegen gebe ich jetzt eben nur die Rechnungsadresse an.
Und weil halt die Domainmodellierung nicht sauber ist, fragen die halt eigentlich nach meiner Wohnadresse, weil die brauchen sie halt für Meldescheine und müssen sie halt irgendwelchen Leuten melden, damit sie halt wissen, wer da genau ist.
So, und da ist eben das Problem, dass halt diese Modellierung nicht sauber ist in diesem typischen Hotelsystem.
Und ich versuche dagegen sozusagen anzuhacken.
Sollten ArchitektInnen Einfluss darauf nehmen, dass die Sprache vielleicht etwas generischer wird?
Naja, also genau genommen ist es halt so, dass wir zwangsläufig diese Sprache jetzt so ein bisschen konkretisieren, weil wir müssen ja irgendwie irgendeine Klasse bauen.
Also ich kann nochmal sozusagen eine Folie zurückgehen.
Und da stellen wir halt irgendwie fest, ich habe hier jetzt im Code irgendwie diese Nali oder Nachlieferung.
Und da sieht man schon nicht, es gibt halt die Nali und die Nachlieferung.
Das eine ist ja irgendwie ein Akronym für das andere.
Oder so eine Abkürzung.
Und jetzt entscheide ich halt, dass ich hier Nachlieferung hinschreibe oder eben Nali.
Damit habe ich jetzt irgendwie einen Begriff herausgegeben, weil das ist der, der halt im Code ist.
Abgesehen davon würde ich das nicht versuchen zu generisch zu machen.
Unser Ziel ist es gerade im Gegenteil exakt für das Businessproblem, was halt dort existiert, eine Lösung zu bauen.
Und dafür würde ich halt versuchen, sehr spezifisch zu sein.
Generalisieren ist halt schwierig, weil ich halt nicht vorhersehen kann, worüber ich halt generalisiere.
Also ich habe hier jetzt nur ein Beispiel, eben eine Nachlieferung.
Was ist das Generelle?
Keine Ahnung.
Und dann ist die Frage, ob ich das halt generalisieren möchte.
Und in vielen Fällen ist eben die Generalisierung, insbesondere eine frühzeitige Generalisierung, schwierig, weil es dazu führt, dass wir halt dann Konzepte haben, die eben doch nicht generell sind.
Und dann wird das System irgendwann unübersichtlich und halt schlecht wartbar, weil man eben die falschen Generalisierungen gewählt hat.
So, das habe ich erzählt.
So, jetzt ist halt die Frage, wie komme ich hier zu meinen Kontexten?
Und das ist eine von den Sachen, wo ich jetzt mit Eventstorming mir schon ein paar Sachen hingelegt habe.
Das heißt, ich kann jetzt hier Kandidaten identifizieren und Kandidaten sind halt genau diese Flächen hier zwischen den Pivotal Events und den Swimlanes.
Das heißt also, ich kann jetzt sagen, okay, ich habe halt einen Bestellprozess, der endet halt damit, dass ich die Bestellung akzeptiere.
Dann gibt es hier irgendwie eine Swimlane, die halt irgendwas macht zum Thema Invoicing.
Dann gibt es hier irgendwie eine Swimlane für Delivery.
Und ich entscheide jetzt, dass eben wir genau diese drei Bauenden Kontexte haben.
Und was ich da jetzt gemacht habe, ist, dass ich halt gesagt habe, hier war ja vorher so ein Pivotal Event in der Mitte von dem Lieferprozess, nämlich da, wo das Paket halt sozusagen rausgegangen ist, aus dem Lager.
Und da habe ich jetzt eben mir entschieden, dass dieser Teil nicht ausreichend ist, um einen neuen Bauenden Kontext anzufangen.
Also die Sprache ist im Wesentlichen identisch.
Ich erschlage das mit im Wesentlichen demselben Code-Modell.
Also ist es ein Modell.
Und das ist eine Diskussion, über die man jetzt, also die Diskussion könnte man führen.
Man könnte halt sagen, ja, da will ich irgendwie was Neues haben.
Ja, genau, das ist halt eine Architektur-Herausforderung.
Was sind die Vorteile?
Also noch ein Hinweis erst mal, das sind nur Kandidaten.
Ich muss mir jetzt immer noch Gedanken über Design machen.
Ich habe hier zum Beispiel, haben wir gesagt, ich habe halt entschieden, dass ein Pivotal Event zumindest jetzt eben nicht diese Systeme aufteilt.
Und dann sind solche Fragen wie, wie ist denn das, wenn ich jetzt Geld zurückbekomme?
Ist es dann so, dass ich das erledige mit demselben Modell wie die Rechnungslegung?
Das ist vielleicht diese Geschichte, die der Nafels vorhin gefragt hat, von wem sollte das eine Generalisierung sein?
Keine Ahnung.
Da könnte man jetzt sagen, dass ich das mit demselben Modell mache.
Also wenn ich jemandem Geld erstatte, gebe ich dem ein Dokument in die Hand und Geld.
Wenn ich eine Rechnung schreibe, habe ich eben eine Rechnung und ich bekomme Geld.
Das könnte sein, dass ich dafür halt irgendwie eben dasselbe Modell baue.
Das heißt, ich habe dann irgendwie einen großen Codeblock, der kann halt Rechnungen schreiben und kann irgendwie auch Rückerstattungen durchführen.
Darüber müsste man dann halt sozusagen diskutieren.
Und dann ist eben genau die andere Frage, wenn ich etwas zurückgebe, wird das eben auch von dem Lieferprozess erledigt?
Das ist eine ähnliche Diskussion.
Auch da ist eben wieder die Frage, ob das wirklich dasselbe ist.
Also da ist es halt so, dass bei einem Lieferprozess eine Ware rausgeschickt wird.
Bei einer Rückgabe kommt eine Ware wieder zu mir rein.
Ist das dasselbe Modell oder nicht?
Keine Ahnung.
Wäre jetzt eben eine Geschichte, die man halt dann fachlich erledigen muss.
Vorteile davon, wir haben damit die Domainlogik strukturiert auf einer grobgranularen Ebene.
Und wenn wir das so machen, wenn wir jetzt also sagen, dass Sachen, die zusammengehören, auch tatsächlich zusammen in einem Bauenden Kontext sind, also Fachlichkeiten in einem Bauenden Kontext implementiert sind, dann impliziert das, dass wir für jede Fachlichkeit auch nur einen Bauenden Kontext benötigen.
Wir haben also Dinge wie, erzeuge mal die Rechnung, berechne die Rechnungsbeträge oder bei Lieferung nicht, schicke irgendwie diesen Klick heraus oder was auch immer.
Und diese Dinge sind halt jeweils in einem Modell implementiert.
Was bedeutet, wenn ich irgendetwas will, lande ich wahrscheinlich im Wesentlichen bei einem Bauenden Kontext.
Und wenn ich irgendwas ändern will, lande ich typischerweise eben auch bei einem Bauenden Kontext.
Es ist klar, dass irgendwelche Änderungen vielleicht auch mehrere Bauenden Kontexte umfassen, aber das ist eher die Ausnahme.
Also ist das, so würde ich behaupten, eine gute Architektur, bei der das eben tatsächlich gut aufteilt.
Herausforderungen, naja, denke ich zu Systeme, weil die haben halt häufig andere Modelle.
Wenn ich Leuten etwas erzähle über Bauenden Kontexte, kommen meistens solche, irgendwelche Wege, wie diese Systeme strukturieren.
Und das ist halt schwierig, hinzugehen zu konsequent die Verantwortung für irgendwelche fachlichen Features irgendwohin verlegen.
Und das ist eben schwer, sich da sozusagen dran zu gewöhnen.
Deswegen auch diese Generik vielleicht für mich ein Problem ist.
Es geht insbesondere um Funktionalitäten.
Also das, was ich hier ja sage, ist, wir haben eben Bestellprozess, Liefern, Rechnung, Schreiben.
Und wir haben gerade nicht Ware, Kunde oder sowas.
Also wir sind bei Funktionalitäten, wir sind nicht bei Daten.
Und die Ergebnisse sind jetzt eben Bauenden Kontexte als Modelle für diese Business-Funktionalitäten.
Kleine, lose, gekoppelte Modelle.
Eine Änderung wird typischerweise nur ein Modell erschlagen, was eben bedeutet, dass ich dort eine lose Kopplung habe.
Ich habe eine Episode gemacht zum Thema Bauenden Kontext, wo ich irgendwie zeige, dass das halt nochmal deutlich schwieriger ist.
Das Konzept ist ein bisschen ambivalent.
Wir haben hier ja schon zwei Sachen gesehen.
Ein Bauenden Kontext ist etwas, was eine Sprache definiert, wo also eine Sprache gültig ist.
Ist aber auch etwas, wo ein Modell gültig ist.
Und dann kommt noch als Drittes hinzu, dass wir dort eben tatsächlich über etwas reden, was Teams typischerweise beschäftigt.
Und dann ist der Begriff sehr stark überladen.
Und das führt dann in der Praxis manchmal zu Schwierigkeiten.
Jan hat geschrieben, ich habe mal den Leitsatz gehört, dass man erst dreimal etwas implementiert haben soll.
Ihr meint es für Allgemeinheit.
Ging eher in Richtung von Reuse.
Da gibt es halt diese Episode mit dem Ich gucke kurz mal.
Da ging es halt genau um dieses Thema.
So schreibt man den nicht.
Ah ja, mit Bert-Jan Schriever über Generic oder Specific.
Da hat er genau das gesagt.
Das ist also eine Maßregel, die man haben kann.
Da sieht man halt, dass eigentlich die Frage ist, was ist fachlich korrekt.
Es ist fachlich korrekt zu sagen, so etwas wie eine Rechnungsregelung und so etwas wie eine Rückgabe, das ist eigentlich dasselbe oder ist das fachlich nicht korrekt.
Das ist eigentlich die Diskussion, die ich führen würde.
Max fragt, wie wichtig ist es, die richtigen Fragen zu stellen.
Das ist super wichtig, klar.
Allgemeinheit im Beratungsbusiness ist ein wichtiges Thema.
Auch eben beim Erstellen des Portals.
Frage 2.
Da schreibt ein Browser, macht Request an einen Port.
Der Port ist in einer Applikation.
Wo ist hier das nicht technische?
Ist der Sticky der Request?
Ja, guter Punkt.
Tatsächlich meine ich damit, im Sinne eines HTTP-Requests oder auch eines Methodenaufrufs, was ich damit meine ist, eine Fachlichkeit ist typischerweise in einbaunem Kontext implementiert.
Darum geht es mir.
Das bedeutet, wenn diese Fachlichkeit genutzt wird, dann lande ich damit bei einbaunem Kontext bei einem Modul.
Genau.
Marc schreibt einen Request an einbaunem Kontext, ein Team, ein Modul.
Gilt das immer noch?
Ja, vielleicht.
Darüber hatte ich ja gesprochen.
Ein Team kann mindestens mehrere baune Kontexte verwalten.
In Wirklichkeit ist es komplizierter, aber eigentlich wollten wir, glaube ich, immer noch ganz gerne in diese Richtung, weil wir dann eine gute fachliche Aufteilung des Systems haben.
Gut.
Dann machen wir, glaube ich, hier mal weiter.
Und das, worum es jetzt als nächstes geht, ist die Geschichte mit der Core-Domain.
Warum ist das relevant?
Weil wir den Fokus verstehen müssen.
Identifikation
Wir müssen verstehen, was ist das, was für uns besonders wichtig ist.
Core Domain
Diese Core-Domain, das ist typischerweise die Motivation für das Projekt.
Da reduzieren wir jetzt die Komplexität dieses Modells.
Insbesondere für diesen Teil wollen wir es reduzieren, damit es besonders gut wartbar und änderbar ist.
Dort soll auch die besonders gute Wartbarkeit sein.
Wir können uns jetzt in diesem System die Frage stellen, wo mag denn hier die Core-Domain sein?
Wir haben Order, Process, Invoicing und Delivery zur Auswahl.
Wie gesagt, das ist ein Vortrag, den ich öfter gehalten habe.
Ihr könnt euch jetzt mal kurz überlegen, was ihr denkt, was die Core-Domain ist.
Die meisten Menschen sagen, dass der Bestellprozess das ist, was die Core-Domain ist.
Vermutlich deswegen, weil da das Geld reinkommt.
Bedeutung
Unsere Differenzierung ist, dass wir schnell und zuverlässig liefern.
Tatsächlich kriege ich in letzter Zeit öfter mal Werbespots zu sehen von einer Firma, die genau das verspricht, sich also versucht, dadurch zu differenzieren.
Deswegen wäre jetzt die Core-Domain dieser Delivery-Prozess.
Wir sagen, hier möchte ich gerne besonders gut sein im Delivery-Prozess.
Das soll besonders gut änderbar sein.
Damit ist das die Core-Domain.
Der Rest wären Generic-Subdomains.
Also Dinge, die man einfach im Extremfall kaufen kann, die also tatsächlich völlig generisch sind.
Oder vielleicht Supporting-Subdomains, wenn die kompliziert sind, ich sie selber baue und die die Kernfunktionalität ergänzen sollen.
Tatsächlich habe ich in einem Projekt gesessen, wo wir genau diesen Bestellprozess gekauft haben.
Das gibt es bei Shopify.
Das, worauf wir uns fokussiert haben, war der Produkt-Configurator, der wahnsinnig kompliziert war.
Das ist genau so ein Beispiel, wo wir jetzt sprechen über die Core-Domain, die in dem Fall der Produkt-Configurator war.
Der Bestellprozess ist ein Generic-Subdomain.
Im Gegensatz zu dem, was die Mehrheit sagt, muss nicht unbedingt die Core-Domain sein.
Wenn wir das herausbekommen, haben wir einen klaren Fokus.
Wir haben auch ein besseres Verständnis der Domäne.
Strategisch weiß ich, wenn ich technische Verantwortung übernehme, Lieferprozess ist wichtig.
Darum muss ich mich ernsthaft kümmern.
Das ist wirklich schlecht, wenn das nicht vernünftig funktioniert.
Ich habe verstanden, wir unterscheiden uns durch den Lieferprozess.
Das bedeutet, ich habe verstanden, wie mein Domänenansatz aussieht.
Das ist eine zusätzliche Information.
Das ist dort der Vorteil.
Da scheinen keine Fragen zu sein.
Dann würde ich mich an der Stelle einfach weitermachen und weiter vorgehen zu Strategic Design.
Da ist die Frage, nicht irgendwie müssen Teams miteinander kollaborieren.
Insbesondere ist es jetzt so, dass wir die Core-Domain haben.
Die Core-Domain muss unterstützt werden durch die anderen Teile des Systems.
Das heißt also, wir müssen jetzt noch dafür sorgen, dass diese Core-Domain erfolgreich ist.
Meine Behauptung ist, das kriegen wir nicht hin, nur mit Architekturhilfsmitteln.
Wir haben den Lieferprozess.
Der Lieferprozess ist zum Beispiel darauf angewiesen, dass der Information von dem Bestellprozess kommt.
Ich kann nichts liefern, wenn ich nicht weiß, wie die Bestellung aussieht.
Damit muss der Lieferprozess eine Schnittstelle anbieten für den Lieferprozess.
Wenn sich etwas ändert, muss der Lieferprozess dementsprechend nachziehen.
Der Bestellprozess muss dem Lieferprozess die richtigen Informationen zur Verfügung stehen.
Ich brauche halt mehr Informationen.
Und dann muss der Lieferprozess sagen, alles klar, das implementieren wir, weil du bist wichtiger als wir.
Nicht Lieferprozess ist das, womit wir uns halt differenzieren.
Und das ist genau das, was als Strategic Domain-Driven Design jetzt eigentlich umsetzt.
Das heißt also, wir müssen jetzt irgendwie die Core-Domain irgendwie.
Priorisieren auf dieser organisatorischen Ebene.
Wir können architekturell nichts machen, wir müssen halt sagen, ihr seid wichtiger.
Und das ist genau das, was Strategic Design sagt.
So ## Strategic Design
Strategic Design hat Patterns, die sich mit Kollaboration herumschlagen.
Also zum Beispiel Customer-Supplier.
Da würde jetzt das Supplier-Team, der Lieferprozess, dem Kunden, das Kundenteam.
Sorry, ich bin irgendwie verwirrt.
Also da würde jetzt der Supplier-Team, der Bestellprozess, würde dem Kundenteam, dem Lieferprozess, den unterstützen.
Das würde also Folgendes bedeuten.
Ich habe das Team für den Bestellprozess und ich habe das Team für den Lieferprozess und ich sage jetzt, du liebes Team, dass du verantwortlich bist für den Lieferprozess.
Du bist der Kunde für das andere Team.
Das heißt, du kannst sagen, ich möchte folgende Dinge haben und dann werden diese Dinge gebaut.
Da gibt es dann natürlich Verhandlungen darüber, wie genau das passieren soll, also nicht.
Da wird diskutiert über Budget, wie lange es dauert.
Wir müssen über Testing reden, wie weit die Schnittstelle testen und so weiter.
Aber im Wesentlichen ist eben dieses Team für den Bestellprozess in einer Hilfsfunktion für den Lieferprozess.
Und das Gegenteil davon wäre das Conformist-Pattern.
Da würde das Team, in diesem Fall also der Bestellprozess ein, dafür sorgen, dass der Lieferprozess in einer Conformist-Rolle ist.
Der Lieferprozess muss mit dem leben, was da ist.
Und das kann sich zum Beispiel dadurch ergeben, dass man sagt Na ja, also ich will ja gerne ändern.
Ich will euch ja gerne andere Informationen zur Verfügung stellen.
Ich will euch gerne unterstützen.
Ich kann es halt nicht, weil unsere Software unänderbar ist.
So, und dann bin ich in einer Conformist-Rolle.
Dann bedeutet das noch nicht, dass ich damit leben muss, was auch immer mir geliefert wird.
Das ist ein Ergebnis von Core Domain.
Das ist das, was jetzt eigentlich der Impact von Core Domain ist.
Und mein Problem hier ist, also soweit ist das, glaube ich, irgendwie alles logisch.
Ich sage also, der Lieferprozess ist irgendwie die Core Domain.
Ich versuche daraus einen Customer zu machen für den Supplier-Bestellprozess und so weiter und so weiter.
Und die Herausforderungen, die ich da halt sehe, sind, das ist halt schwer, das halt tatsächlich auf die Reihe zu bekommen.
Herausforderungen
Und es ist relativ kompliziert.
Also ich habe hier jetzt zwei Patterns gezeigt, weil ich halt, weil ich halt keine Lust hatte, die zehn Patterns oder was auch immer es sind, halt komplett irgendwie alle aufzumalen.
Und es ist halt auch nicht sonderlich intuitiv.
Diese beiden Patterns sind noch intuitiv.
Aber es gibt dann halt Patterns, die andere Dinge definieren, die also zum Beispiel sagen, sowas wie Published Language.
Es gibt eine gemeinsame Datenstruktur.
Das hat wenig mit Priorisierung zu tun.
Da rede ich ja plötzlich über Datenstrukturen.
Und deswegen ist es halt für mich so, dass ich da halt insgesamt pessimistisch bin, weil es eben nicht intuitiv ist.
Es wirkt zu kompliziert.
Und das ist, wie soll ich sagen, keine abstrakte Kritik, sondern das führt eben tatsächlich dazu, dass es meiner Ansicht nach wenig adaptiert wird.
Also es ist tatsächlich so, dass es zu echten Schwierigkeiten führt, weil es eben für Menschen schwierig ist, das umzusetzen.
Und der andere Punkt ist, hier wird eigentlich nur über Teams gesprochen.
Hier hat er irgendwie Baune Kontexte beackern.
Und wenn ich jetzt zum Beispiel so eine Entwicklungsplattform baue, dann baue ich ja keinen Baune Kontext.
Und das ist streng genommen irgendwie nicht mehr Teil dieser Patterns, weil ich eben keinen Baune Kontext baue.
Und das ist irgendwie mindestens konzeptionell halt auch problematisch, weil ich habe Teams, die sich um andere Dinge kümmern, nicht nur um Baune Kontexte.
Und deswegen finde ich mittlerweile Strategic Design halt auch schwierig.
Genau, Frage 2 hat gesprochen, kann man Ergebnisse von DDD noch in Schichtlayers oder Schichtarchitektur bilden?
Dazu diskutieren wir beim nächsten Mal.
Also tatsächlich ist Layers ein DDD-Pattern.
Marc M. hat geschrieben, viele Architekten verwenden den Begriff Business Capabilities.
Das scheint so etwas wie eine Task-Definition zu sein.
Kommt das bei dir in deinem Ansatz auch als Begrifflichkeit vor?
Nein, tut es nicht.
Und das ist irgendwie auch Domain-Domain-Design by the book.
Also Business Capabilities ist etwas, was ich eher so aus Enterprise Architekturmanagement kenne.
So, wenn ich halt sage, dass das mit dem Strategic Domain-Domain-Design so ein bisschen problematisch ist, dann fühle ich mich halt dazu verpflichtet, irgendwie zu sagen, wie ich es denn besser machen kann.
Und dazu möchte ich halt noch mal kurz auf Team Topologies eingehen.
Dort ist, also irgendwie müssen ja jetzt Teams miteinander kollaborieren.
Und ## Team Topologies
Team Topologies ist meiner Ansicht nach eben nicht so super kompliziert.
Relativ intuitiv.
Ich zumindest finde es halt irgendwie klarer.
Und es enthält mehr Fracture-Plans als nur bauende Kontexte.
Also zum Beispiel auch sowas wie Location.
Das heißt, dort wird irgendwie nicht gesagt, okay, wir teilen die Teams halt nur nach Fachlichkeiten auf, sondern da wird irgendwie gesagt, es gibt eben auch andere Sachen, wie zum Beispiel, wenn Teams irgendwo zusammensitzen oder Menschen zusammensitzen, dann können sie ja vielleicht eher ein Team bilden.
In Zeiten von Remote-Arbeit ist das etwas, was vielleicht zunehmend weniger wichtig wird.
Aber sonst, wenn man sich gewohnt sein in einem Raum treffen kann, ist das halt häufig ein Vorteil.
Und wir reden ja über mehr als nur Entwicklungsteams.
Was gibt es dort?
Teamtypen
Es gibt Stream-Aligned Teams.
Stream-Aligned Teams sind Teams, die eben an einem Änderungsstrom den vollständig abdecken.
Also von Anforderung bis es halt in Produktion ist.
Dann gibt es Enabling Teams.
Teams, die halt diese Stream-Aligned Teams dabei unterstützen, um welche Fähigkeiten aufzubauen.
Dann gibt es Plattform-Teams, die also irgendeine Plattform anbieten.
Kubernetes, CI, vielleicht auch irgendwas Geschäftsmäßiges.
Also vielleicht irgendwie ein Zahlsystem oder so.
Complicated Subsystem Team, die eben welche komplizierten Algorithmen halt umfassen.
So und in meinem Beispiel, also und da gibt es verschiedene Kollaborationsmöglichkeiten.
Kollaboration
Access to Service bedeutet, dass ich eine Schnittstelle implementiere.
Das könnte so ein Complicated Subsystem tun oder ein Plattform-Team.
Diese Schnittstelle könnte entweder programmatisch sein oder eben eine Schnittstelle, die ich über eine Benutzeroberfläche benutzen kann.
Und dann gibt es sowas wie Facilitating.
Also, dass ich mir anschaue, was die Teams zu tun in einem bestimmten Bereich und sie dabei unterstütze.
Oder Collaboration bedeutet sogar, dass ich halt irgendjemanden ausleihe, der dann aktiv mit diesem Team zusammenarbeitet an einer bestimmten Herausforderung.
So, das können wir jetzt auf unserem Fall unterbrechen.
Das heißt, ich habe Invoicing, Bestellprozess und den Lieferprozess.
So, dann habe ich halt irgendein Ding, was irgendwie sagt, wie ich Sachen rausliefern möchte.
Da ist zum Beispiel diese Logik für diese Nachlieferung.
Und die bieten jetzt so eine Schnittstelle, eine Access to Service hin für die Lieferung.
Das heißt also, dieses Team hier, Lieferung ist verantwortlich für irgendeine Änderung, die dort passiert, von Analyse bis zu einer Produktion geht.
Und die bieten jetzt irgendein Ding an, dem ich halt sage, du, der E-Mart hat irgendwie folgende Dinge bestellt, was auch immer es sein mag, einen Laptop und eine Waschmaschine.
Wie kriege ich das denn irgendwie zu ihm geliefert?
So, dann wird das System irgendwie sagen, okay, bedauerlicherweise müssen wir eine Spedition losschicken für die Waschmaschine und den Laptop müssen wir extra machen.
Wenn es was anderes gewesen wäre, nicht, wenn ich halt irgendwie zwei Laptops bestellt hätte, hätte das vielleicht zusammengefasst, was auch immer da hat irgendwie passiert.
So, und das ist jetzt eben tatsächlich ein sehr spezifischer Algorithmus.
Da kann man sich vorstellen, dass es irgendwie sehr kompliziert ist, den halt umzusetzen.
Und das wird jetzt eben diesem Team angeboten als reine Fachlichkeit.
Und in bauenden Kontexten ist das vielleicht derselbe bauende Kontext, diese Optimierung und der Lieferprozess.
Hier trennen wir es halt, weil wir eben sagen, dieser Algorithmus ist so kompliziert.
Und das ist jetzt eben etwas, was dieses andere Team hat erledigt.
Dann haben wir das Kubernetes CI Team.
Das bietet halt eben Kubernetes Cluster an und sorgt dafür, dass man die über eine Webseite buchen kann oder über eine Schnittstelle.
So, dann gibt es das Architektur Team, was entweder dafür sorgt, dass die anderen Teams Architekturskills aufbauen oder vielleicht auch mal jemanden ausleihen, um jetzt dafür zu sorgen, dass dort irgendein Architekturproblem mal wirklich gelöst wird.
Also wir setzen uns jetzt gemeinsam hin und wir bauen mal das Ding wirklich fertig, damit das Team diesen Skill aufbaut.
Und gleichzeitig ist das ja auch ein Feedback Kanal.
Das heißt, ich kriege mit, wo Schwierigkeiten sind und ich kriege als Architektur Team mit, wo ich besser werden muss.
So, Ergebnisse, das Team Setup ist damit definiert und auch die Kollaborationen sind definiert.
Herausforderung noch, das sind Magnete.
Also das ist irgendwie ein Zielbild und ich habe dazu eine Episode gemacht.
Hier ist auch nochmal das Plakat, was die Lisa halt erstellt hat dafür.
Kann man sich da auch runterladen.
Da kann man sich das eine Stunde angucken und ich habe mit der Kim zusammen nochmal so ein paar Praxistinge dazu diskutiert.
Da möchte ich jetzt nochmal eingehen auf dieses Problem mit den Org Charts.
Also Beispiel, ich habe jetzt Streamline Teams und ich will halt in einem Plattform Team irgendwelche gemeinsamen Funktionalitäten übernehmen.
Irgendwelche gemeinsamen Geschäftsfunktionalitäten.
Und das ist jetzt eine Geschichte, wo ich jetzt sagen würde, hey, abstrakt kann das vielleicht Sinn machen.
Das bedeutet, dass ich jetzt hier so aus einer reinen Architektur Perspektive sagen kann.
Hör mal zu, wir untersuchen das.
Ja, das sind tatsächlich gemeinsame Funktionalitäten.
Wir implementieren das halt einmal sozusagen zentral.
So, also das war hier die Frage, sollen wir mit dem Plattform Team involvieren?
Da gibt es ja irgendwelche gemeinsamen Funktionalitäten und das macht vielleicht irgendwie Sinn.
Aber da war es eben eine toxische Umgebung.
Probleme sind nicht kommuniziert worden.
Und wenn man gesagt hat, ich habe ja übrigens Probleme, dann hat es eben wie entsprechend eine Strafe gegeben.
Und das führt jetzt zu folgenden Problemen.
Ich kann halt, also wenn ich mich jetzt hinsetze und sage, ich bin ein Streamline Team und ich will diese Plattform benutzen, dann kann ich dem Plattform Team nicht vertrauen.
Und ich kann halt nicht sagen, ich bin ein Streamline Team.
Ich kann dem Plattform Team nicht vertrauen, weil die ihre Probleme nicht offen kommunizieren werden.
Das heißt, die werden ihre Probleme eher verstecken.
Und dann habe ich ein Risiko, weil ich bin halt ein Streamline Team.
Ich muss halt irgendwelche Ziele erreichen und ich bin jetzt abhängig von diesem Plattform Team.
Vielleicht erreiche ich die nicht wegen des Plattform Teams.
Und dann habe ich das Problem, dass irgendwie dieses Streamline Team dafür, also ich werde dafür bestraft und ich habe offiziell versagt.
Und dann werde ich wahrscheinlich irgendwie sagen, okay, ich baue die Plattform selber, weil dann habe ich es unter Kontrolle.
Dann weiß ich, dass ich ein Problem habe, ich kann es managen.
Und das ist eine Entscheidung, die halt völlig unabhängig ist von der Frage, ob das sozusagen fachlich Sinn macht, sondern die nur davon getrieben ist, dass ich versuche, meine Risiken zu managen.
Und das bedeutet, dass wir hier vielleicht auch ein allgemeineres Problem haben.
Also Menschen arbeiten eben nicht notwendigerweise so, wie es in den Org Charts steht.
Das heißt, sie muss halt diese Probleme erst mal lösen.
Und wir haben halt informelle Kommunikationskanäle.
Also ich kann mit irgendwelchen Leuten informell reden, kann halt irgendwie dafür sorgen, dass die das halt sozusagen lösen.
Und das ist dann ein Thema, wo ich eben, da haben wir ja ganz viele Episoden gemacht.
Zum Beispiel haben wir auch zu Fair Dischange, die ich halt für mich arbeiten lassen kann.
Aber das ist dann eben auf einer anderen Ebene etwas.
Und ich habe diese Folie noch eingefügt, weil eine Org Chart zu malen, so wie das halt, so wie das eben gesagt wird bei Team Topologies, das ist eben nicht ausreichend.
Und das sagt das Team Topologies Buch selber auch.
Also dieses Problem mit Org Charts ist ein Kapitel Überschrift aus dem Team Topologies Buch.
Der Nafez Nesnif schreibt, Leider gibt es immer wieder Stress bei den Zuständigkeiten in den verschiedenen Teams bei dem Ansatz.
Vielleicht ist das dann eben eine Ursache dafür, nicht also diese informellen Kanäle und was ist überhaupt eine Zuständigkeit?
Wie soll ich sagen?
Das ist etwas, was auch tatsächlich eben im Consulting oft einmal ein Thema ist, nicht Team Zuständigkeiten sozusagen klären.
Ich bin nicht sicher, ob ich das durch Org Charts malen auf die Reihe bekomme.
Und genau, also Jan hat es gerade geschrieben, Org Charts ist halt kein Kommunikationschart.
Und das ist etwas, was, wo ich muss mal kurz den Gedanken sammeln, also wo, weswegen ich ja dieses Beispiel gewählt habe, nicht?
Also ich habe mir gesagt, okay, es macht vielleicht Sinn, dieses Plattform-Team zu haben, aber durch Misstrauen ist es vielleicht so, dass ich es halt tatsächlich nicht umsetzen kann.
Und dann habe ich da letztendlich ein Problem.
So, Frage zweierlei, It Depends schreibt Eigenrationalitäten.
Also jedes Team hat Eigenrationalitäten.
Dadurch entstehen Risiken für andere Teams und Vorteile.
Ich glaube, ehrlich gesagt, also wir haben diese Episode gemacht, habe ich gemacht zusammen mit meinem Kollegen Michael über dieses Thema mit Unternehmenspolitik.
Und ja, Eigenrationalität und die eigenen Ziele abzuwägen gegeneinander ist, glaube ich, ein wesentlicher Punkt für eben Unternehmenspolitik, um dort diesen Ausgleich hinzubekommen.
Ich glaube, dass das in Wirklichkeit vielleicht auch noch ein bisschen weitergeht.
Sprich, es kann irgendwie sein, dass halt einige Teams auch, deswegen habe ich ja dieses toxische Beispiel gewählt, tatsächlich eben nicht hilfreich sind, vielleicht gezwungen durch Umgebung und sind vielleicht nicht hilfreich.
Und im Extremfall kann es sogar so sein, dass es halt, wie soll ich sagen, einen Wettbewerb gibt und halt eine unangenehme Gesamtsituation, die dazu führt, dass es halt so einen destruktiven Wettbewerb gibt.
Das würde ich nicht ausschließen.
Dann habe ich aber ein ganz anderes Set von Problemen und das ist sicherlich nicht mit OrgChats lösbar.
Und dann gibt es halt vielleicht auch auf dieser Ebene keine ernsthafte Lösung.
Der Philipp Sporrer schreibt, wie identifiziert man die Streams?
Also gibt es dafür Methoden, heuristiken?
Um es nochmal zu sagen, diese Streams sind Änderungs-Streams.
Das heißt, das geht von Anforderung bis hin dazu, dass irgendwas umgesetzt wird und also bis es halt in Produktion geht.
Das heißt, im Wesentlichen sind das also Streams, die dafür sorgen, dass wir etwas umsetzen können und es bis in Produktion geht.
Und das Besondere bei Team Topologies ist, dass es dort eben eine Vielzahl von Fracture Plans gibt, die ganz unterschiedliche Dinge dann solchen Stream Align Teams zuweisen können.
Also hier haben wir ja gesehen, es gibt zum Beispiel auch eine Kontexte.
Ich finde das irgendwie auch ein ganz gutes Modell.
Ich könnte zum Beispiel auch so was haben wie Personas, also Neukunden versus Bestandskunden, wäre halt eine Möglichkeit.
Und ich kann zum Beispiel auch so was haben wie eine UI.
Also nicht nur UI, kann ich halt auch sagen, ich möchte diese Änderung und dann gebe ich das halt bis in Produktion durch und das könnte halt ein Stream Align Team machen.
Das bedeutet, diese Stream Align Teams sind eigentlich sehr flexibel, weil das eben bedeutet, dass halt fast beliebige Änderungskanäle oder Änderungs Ströme dort denkbar sind.
So deswegen ist noch ein bisschen diese Frage, wie identifiziert man die?
Die ist ein bisschen, wie soll ich sagen, das ist nicht die Frage.
Ich weise denen etwas zu, diesen Teams, und da ist eben Team Tomatologie ist tatsächlich relativ flexibel.
Ich frage zwei, drei, schreibt schön, dass du Umgebungsvorwärte mit einbruchst.
Bitte Antwort bei dem eigenen Rationalitätsthema.
Genau, vielen Dank.
Achso, auch danke für die.
Da war noch mehr positives Feedback und Menschen, die halt sozusagen Likes da gelassen haben.
Vielen Dank dafür auch.
Dann wären wir, glaube ich, soweit tatsächlich durch und wir können noch mal sozusagen den Blick nach vorne wagen.
Da gibt es am 29.
Das ist die übernächste Woche die Episode mit dem Lars.
Ralf spricht mit Lars zum Thema Generative AI Beans Software Architecture und ja, dann wird es wohl Freitag eine Episode geben, wo ich das hier fortsetze und dann halt über taktisches Design spreche.
Ich will nicht ausschließen, dass es eine dritte Episode dazu noch geben wird.
Das werden wir dann sehen.
Hängt halt davon ab, wie es da weitergeht.
Gut, schon mal kurz, ob ich irgendwas vergessen habe.
Das scheint aber nicht der Fall zu sein.
Dann würde ich sagen, ja, vielen Dank fürs Zuschauen.
Vielen Dank für das positive Feedback.
Vielen Dank für die Fragen und dann sehen wir uns beim nächsten Mal.
Genau.
Bis dahin.