Von Stories zu Code: Wie Domain Storytelling und EventStorming LLMs den nötigen Kontext geben

1. Das gebrochene Versprechen KI-gestützter Entwicklung

Inzwischen haben die meisten Entwicklungsteams versucht, ein LLM zur Code-Generierung einzusetzen. Die Ergebnisse sind vertraut: syntaktisch korrekt, oberflächlich plausibel und häufig falsch auf eine Weise, die Stunden zur Diagnose benötigt. Das Modell generiert selbstsicher Endpunkte, die die eigene Domäne nicht widerspiegeln, Schemas, die Geschäftsregeln verfehlen, und Strukturen, die vernünftig aussehen – bis ein Domänenexperte eine einzige Frage stellt und das Ganze auseinanderfällt.

Die Versuchung ist groß, dem Modell die Schuld zu geben. Aber das ist die falsche Perspektive.

LLMs scheitern bei der Domänenarbeit nicht, weil sie nicht smart sind. Sie scheitern, weil sie keinen Zugang zu deiner Domäne haben. Sie wissen nicht, dass ein Koch sein eigenes Rezept nicht bewerten kann. Sie wissen nicht, dass ein Rezept einen eindeutigen Titel benötigt. Sie wissen nicht, dass „Making" und „HowTo" dasselbe Konzept in zwei verschiedenen Gesprächen sind. Sie produzieren plausiblen generischen Code, weil plausibler generischer Code das ist, womit sie trainiert wurden – und solange man ihnen nichts Präziseres gibt, werden sie genau das weiterhin produzieren.

Die fehlende Zutat ist kein besseres Modell oder ein clevererer Prompt. Es ist eine bessere Spezifikation. Und genau hier kommt das kollaborative Modellieren ins Spiel.

Dieser Beitrag zeigt, wie Domain Storytelling [1] und EventStorming [2] – Techniken, die die meisten von euch bereits kennen – Artefakte erzeugen, die nicht nur für die menschliche Kommunikation nützlich sind, sondern auch direkt als LLM-Kontext verwendbar sind. Das Ergebnis ist eine Prototyp-Pipeline, bei der jeder Modellierungsschritt die Mehrdeutigkeit reduziert und messbar bessere generierte Ausgaben liefert. Wir demonstrieren dies konkret anhand von Larder, einer Rezepte-Sharing-Plattform, die wir von Grund auf in drei Prototyp-Iterationen aufgebaut haben.

---

2. Die Kernidee: Mehrdeutigkeit ist der Feind

Ein LLM-Prompt ist nur so gut wie der Kontext, den er enthält. Das ist keine strittige Aussage – es ist die grundlegende Einschränkung, wie diese Modelle funktionieren. Vage Eingaben liefern vage Ausgaben. Präzise, strukturierte, domänenbasierte Eingaben liefern präzise, strukturierte, domänenbasierte Ausgaben.

ⓘ HINWEIS: Mehrdeutigkeit ist der Feind, seit die erste Software geschrieben wurde. Es ist kein neues Problem. Eric Evans hat dieses Problem bereits 2003 in seinem wegweisenden Werk „Domain-Driven Design" [3] behandelt.

Die Herausforderung besteht darin, dass die meisten Entwickler LLM-gestütztes Prototyping so angehen wie eine Google-Suche: eine kurze Beschreibung dessen, was sie wollen, und das Modell soll den Rest ergänzen. Das Modell kommt dem nach – und füllt den Rest mit generischen Annahmen, die aus den Tausenden ähnlicher Systeme abgeleitet werden, die es während des Trainings gesehen hat.

Kollaborative Modellierungstechniken lösen ein anderes Problem für menschliche Teams: Sie fördern implizites Wissen zutage, lösen Mehrdeutigkeiten auf und bauen ein gemeinsames Verständnis auf. Als Nebeneffekt erzeugen sie jedoch Artefakte – Domain Stories [1], Event Boards [2], Visual Glossaries [4], die als LLM-Eingabe bemerkenswert gut strukturiert sind. Die piktografische Sprache von Domain Storytelling lässt sich sauber auf Akteure und Arbeitsobjekte abbilden. Die Befehls-/Ereignis-/Richtlinienstruktur von EventStorming [2] lässt sich direkt auf API-Operationen und Geschäftsregeln abbilden. Eine aus diesen Artefakten abgeleitete OpenAPI-Spezifikation [5] ist im Wesentlichen ein maschinenlesbares Domänenmodell.

Der rote Faden, der alle drei verbindet, ist die Ubiquitous Language [3] – das gemeinsame Vokabular, das aus kollaborativen Modellierungssitzungen entsteht und mit jedem Schritt präziser wird. Im Kontext LLM-gestützter Entwicklung bestimmt die Qualität dieser Sprache direkt die Qualität der generierten Ausgabe.

Die Pipeline, die wir demonstrieren werden, hat drei Schritte:

• Domain Storytelling – erfasst die Absicht und erzeugt ein erstes Vokabular
• EventStorming – schärft dieses Vokabular zu Ereignissen, Befehlen und Richtlinien
• OpenAPI-Spezifikation – kodiert das Ergebnis als maschinenlesbaren Vertrag

Bei jedem Schritt übergeben wir die Artefakte direkt an ein LLM und generieren einen Prototyp. Schauen wir, was passiert.

---

3. Schritt eins – Domain Storytelling: Absicht erfassen

Das Artefakt

Wir haben einen Domain Storytelling-Workshop für Larder durchgeführt und folgende Geschichte produziert:

Ein anonymer Benutzer registriert sich über die App und wird zum Koch. Ein Koch bereitet eine Mahlzeit vor und teilt ein Rezept, optional mit Fotos. Ein anderer Koch probiert dieses Rezept, macht dabei ebenfalls optional Fotos, und bewertet es.

Die piktografische Story erfasst sechs nummerierte Aktivitäten über zwei Koch-Akteure hinweg und macht die Rollenunterscheidung zwischen Autor und Bewerter visuell explizit. Dazu haben wir ein erstes Visual Glossary erstellt, das drei Bounded Contexts identifiziert – Register, Sharing und Rating – und die Struktur der Schlüsselkonzepte detailliert: Koch (mit E-Mail), Rezept (mit Zutaten, Zubereitung und Schritten) und Bewertung (mit Sternen und optionalem Foto).

Das Glossary machte auch eine Vererbungsbeziehung sichtbar: RatedRecipe erbt von Recipe.

Die Artefakte in einen Prompt umwandeln

Anstatt die Artefakte in Text zu übertragen, haben wir beide Bilder direkt an das LLM angehängt:

Based on these two modeling artifacts for a platform called Larder, generate a runnable REST API using Node.js and Express with in-memory storage. No authentication required beyond identifying the current Cook by ID. Do not add any features or concepts not visible in the artifacts.

Die Anweisung, nichts hinzuzufügen, was nicht in den Artefakten sichtbar ist, ist bewusst gewählt. Sie hält das LLM ehrlich und macht Lücken sichtbar – genau das, was wir für dieses Experiment wollen.

Was das LLM produzierte

Die Ausgabe war überraschend ausgereift. Claude Code generierte nicht nur Route-Dateien, sondern auch eine vollständige OpenAPI 3.1-Spezifikation neben der Express-Implementierung und verwendete express-openapi-validator, um alle Anfragen dagegen zu validieren. Die drei Bounded Contexts wurden sauber in Route-Gruppen übersetzt. Das Ingredient-Schema mit name, number und unit war pixelgenau aus dem Glossary. RatedRecipe mit allOf zur Vererbung von Recipe spiegelte die Glossary-Beziehung korrekt wider.

Hier ist ein repräsentativer Auszug aus der generierten Spezifikation, der die Rating-Schemas zeigt:

1Rating:
2  type: object
3  required: [id, cookId, recipeId, stars]
4  properties:
5    id:
6      type: string
7    cookId:
8      type: string
9    recipeId:
10      type: string
11    stars:
12      type: integer
13      minimum: 1
14      maximum: 5
15    pictures:
16      type: array
17      items:
18        $ref: '#/components/schemas/Picture'

• OpenAPI
• Service nach Domain Storytelling

Sauber, korrekt und direkt auf das Visual Glossary zurückverfolgbar.

Wo es scheiterte

Drei Lücken fallen auf – und sie liegen genau dort, wo die Domain Story und das Visual Glossary mehrdeutig waren:

Die Selbstbewertungsregel fehlt vollständig. Die Geschäftsregel „ein Koch kann sein eigenes Rezept nicht bewerten" existierte in unserem Gespräch, war aber in keinem Artefakt sichtbar. Das generierte ratings.js enthält keine Prüfung dafür. Das ist kein LLM-Versagen – es ist ein Artefakt-Versagen. Das Modell hatte keine Möglichkeit zu wissen, dass die Regel existiert.

ⓘ HINWEIS: Dies ist eine Erinnerung daran, dass jede Entscheidung oder Regel, die in einem Workshop ans Licht kommt, sofort festgehalten werden sollte. Eine einfache Konvention: rote Haftnotizen für Regeln, Einschränkungen und offene Fragen, die noch nicht im Modell abgebildet sind.

Meal ist getrennt. Die Domain Story zeigt, dass ein Koch eine Mahlzeit vorbereitet und dann ein Rezept teilt, was eine Beziehung impliziert. Das LLM modellierte sie als zwei separate, unabhängige Ressourcen. MealInput hat nur Fotos und keinen Link zu Recipe.

Making wurde stillschweigend aufgelöst. Im Visual Glossary war es ein eigenständiges Konzept, das Koch → Rezept → Schritte verband. Im generierten Code wurde es einfach zu einem Inline-Array von Steps auf Recipe – eine Modellierungsentscheidung, die das LLM ohne jede domänenfachliche Begründung traf.

Diese Lücken sind keine Randfälle. Ein Koch, der seine eigenen Rezept-Rankings manipuliert, eine getrennte Meal-Entität und ein stillschweigend zusammengefasstes Domänenkonzept sind genau die Art von Problemen, die in der Produktion auftauchen und erhebliche Zeit zur Behebung benötigen. Und sie alle haben dieselbe Ursache: Die Artefakte enthielten dieses Wissen noch nicht.

---

4. Schritt zwei – EventStorming: Die Sprache schärfen

Das Artefakt

Wir haben eine EventStorming-Sitzung mit der Domain Story als Ausgangspunkt durchgeführt. Das Board enthüllte drei Bounded Contexts mit klaren visuellen Grenzen: Register, Sharing und Rating.

Innerhalb dieser Kontexte ergab sich Folgendes:

Im Sharing-Kontext: Der Befehl ShareRecipe erzeugt das Ereignis RecipeShared. Der Befehl TakePictures erzeugt PicturesTaken. Eine Einschränkung tauchte auf: Rezept benötigt einen eindeutigen Titel.

Im Rating-Kontext: Der Befehl RateRecipe erzeugt RecipeRated. Eine Richtlinie erschien explizit: Eigene Rezepte können nicht bewertet werden. MealCooked und RecipeTried wurden bewusst als „Nicht in der App" markiert – eine Scoping-Entscheidung, die verhindert, dass das LLM toten Code generiert.

Das verfeinerte Visual Glossary ergänzte deutlich, was die Domain Story erfasst hatte:

• Koch hat jetzt Name und GivenName neben der E-Mail
• Rezept erhielt Title, Servings, Meal (als Enum: Breakfast, Lunch, Dinner, Dessert) und Diet (Normal, Vegetarian, Vegan)
• Making wurde in HowTo umbenannt – eindeutig und direkt code-nah
• ShoppingList erschien als völlig neues Konzept, mit Items, die jeweils Product, Number und einen Link zum Kauf haben
• Rating erhielt ein Note-Feld (Text, maximal 1024 Zeichen) und ein explizites Rater-Feld, das sich vom Rezeptautor unterscheidet

Die Artefakte in einen Prompt umwandeln

Für Prototyp v2 starteten wir eine frische Claude Code-Sitzung – ohne Erinnerung an v1 – und hängten beide EventStorming-Bilder mit folgendem Prompt an:

You are building Prototype v2 of Larder. Follow a strict API-first approach: 1. Derive the OpenAPI 3.1 spec from the modeling artifacts above — this is your single source of truth 2. Generate the Node.js + Express implementation from the spec, validated against it using express-openapi-validator 3. Do not add any concept, field, or endpoint not visible in the artifacts

Apply the following rules strictly, all of which are explicit in the artifacts:

• A Recipe must have a unique Title
• Own recipes cannot be rated
• MealCooked and RecipeTried are out of scope — do not implement them
• A Rating may include a Note of maximum 1024 characters

Drei Dinge änderten sich bewusst gegenüber dem v1-Prompt. Die API-First-Anweisung ist jetzt explizit und geordnet – Spezifikation vor Code. Die Geschäftsregeln aus den EventStorming-Richtlinien-Haftnotizen werden direkt benannt. Und die Out-of-Scope-Entscheidungen werden explizit angegeben – dem LLM zu sagen, was es nicht bauen soll, ist genauso wichtig wie zu sagen, was es bauen soll.

Was sich in der Ausgabe änderte

Die Differenz zwischen den OpenAPI-Spezifikationen v1 und v2 erzählt die Geschichte klarer als jede Beschreibung:

V1-Spezifikation: 3 Schemas mit Domänenbedeutung. V2-Spezifikation: 9 Schemas. Dreimal so viel Domänenausdruckskraft – vom selben LLM, rein durch reichhaltigere Eingabeartefakte.

Im Einzelnen:

Die 403-Antwort existiert jetzt auf POST /recipes/{recipeId}/ratings:

1'403':
2  description: Koch kann sein eigenes Rezept nicht bewerten.
3  content:
4    application/json:
5      schema:
6        $ref: '#/components/schemas/Error'

Eine Richtlinien-Haftnotiz auf einem EventStorming-Board wurde direkt in einen korrekt typisierten HTTP-Antwortcode übersetzt.

Recipe in v2:

1RecipeCreate:
2  type: object
3  required: [title, ingredients, howTo, servings, meal, diet]
4  properties:
5    title:
6      type: string
7    ingredients:
8      type: array
9      minItems: 1
10      items:
11        $ref: '#/components/schemas/Ingredient'
12    howTo:
13      type: array
14      minItems: 1
15      items:
16        $ref: '#/components/schemas/Step'
17    shoppingList:
18      type: array
19      items:
20        $ref: '#/components/schemas/ShoppingItem'
21    servings:
22      type: integer
23      minimum: 1
24    meal:
25      $ref: '#/components/schemas/Meal'
26    diet:
27      $ref: '#/components/schemas/Diet'

• OpenAPI nach EventStorming
• Serverversion nach EventStorming

ShoppingList, Meal, Diet, servings, title – nichts davon existierte in v1. Sie wurden nicht vom LLM erfunden. Sie kamen vom EventStorming-Board und dem verfeinerten Visual Glossary.

Eine weitere strukturelle Änderung ist erwähnenswert: RatedRecipe verschwand. In v1 hatte das LLM ein hybrides Antwortobjekt konstruiert, das Recipe und Rating kombinierte. In v2, mit klareren Bounded-Context-Grenzen auf dem EventStorming-Board, sind Rating und Recipe ordnungsgemäß getrennte Aggregate. Die Spezifikation wurde einfacher, nicht komplexer, als das Domänenwissen präziser wurde. Das ist ein Muster, das es zu erkennen gilt: Mehr Domänenklarheit bedeutet oft weniger zufällige Komplexität in der Ausgabe.

---

5. Schritt drei – Die API-Spezifikation als maschinenlesbarer Vertrag

Aufteilen nach Bounded Context

Da v2 eine saubere, gut strukturierte Spezifikation lieferte, war der natürliche nächste Schritt, das EventStorming-Board die Architektur explizit steuern zu lassen. Drei Bounded Contexts auf dem Board wurden zu drei unabhängigen OpenAPI-Spezifikationen:

• register.yaml – besitzt die Koch-Identität, Registrierung und Suche, keine Abhängigkeiten
• sharing.yaml – besitzt die vollständige Rezeptstruktur, hängt von Koch nur über den X-Cook-Id-Header ab
• rating.yaml – besitzt Bewertungen, referenziert Rezept nur über recipeId im Pfad

Diese Trennung macht einen architektonischen Punkt deutlich, der über das Prototyping hinausgeht: Bounded Contexts teilen IDs, keine Schemas. sharing.yaml importiert Cook nicht aus register.yaml. rating.yaml importiert Recipe nicht aus sharing.yaml. Die Kontexte sind auf Vertragsebene lose gekoppelt, was bedeutet, dass sie sich unabhängig weiterentwickeln können.

Wir behielten die Implementierung als Monorepo mit drei Express-Routern, jeder gegen seine eigene Spezifikation validiert. Das ist es wert, explizit zu sagen: Der Bounded Context ist eine architektonische Grenze, nicht unbedingt eine Deployment-Grenze [6]. EventStorming sagt dir, wo die Grenzen sind. Wie du über diese Grenzen hinweg deployest, ist eine separate Entscheidung, die von betrieblichen Anforderungen getrieben werden sollte, nicht von einer reflexartigen Zuordnung von Kontext zu Microservice.

Die Spezifikationen als Ergebnis

In einem echten API-First-Ansatz ist die Spezifikation das Ergebnis. Die Implementierung, die folgt, ist mechanisch. Die drei YAML-Dateien sind Prototyp v3 – nicht nur der Node.js-Code, der sie implementiert.

Das ist der wichtigste Punkt der gesamten Pipeline: Sobald man drei saubere, domänenausgerichtete OpenAPI-Spezifikationen hat, die aus kollaborativen Modellierungsartefakten abgeleitet wurden, ist die schwere Arbeit erledigt. Was bleibt, ist die Ausführung – und LLMs sind sehr gut in der Ausführung, wenn man ihnen einen präzisen Vertrag gibt, gegen den sie ausführen können.

Wir hängten alle drei Spezifikationen direkt an und verwendeten folgenden Prompt:

Baue eine Single-Page-React-Anwendung für Larder. Die drei angehängten OpenAPI-Spezifikationen sind deine einzige Quelle der Wahrheit. Decke folgende User Journeys ab, die strikt aus den Spezifikationen abgeleitet sind: als Koch registrieren, ein Rezept teilen, Rezepte durchsuchen, ein Rezept bewerten. Füge kein Feature, Feld oder Screen hinzu, das nicht aus den Spezifikationen ableitbar ist.

Wieder eine frische Sitzung – keine Erinnerung an v1 oder v2.

Das Ergebnis war eine lauffähige Webanwendung. Der Rezept-Detailscreen zeigte „Scones" mit Badges für „Breakfast", „Vegetarian" und „3 servings" – das Meal-Enum, das Diet-Enum und das servings-Feld, die in Prototyp v1 nicht existierten, während EventStorming entdeckt, in der Spezifikation kodiert und vom LLM ohne zusätzliche Anweisung treu gerendert wurden.

Nichts auf diesem Screen wurde erfunden. Jedes Feld, jedes Label, jede Struktur kam von einer Haftnotiz oder einem Piktogramm.

---

6. Die Ubiquitous Language als roter Faden

Blickt man auf alle drei Prototypen zurück, hat dasselbe Konzept einen langen Weg zurückgelegt:

Was als Piktogramm mit der Bezeichnung „Recipe" in der Domain Story begann, wurde zu einem strukturierten Knoten im Visual Glossary mit Ingredients, HowTo und Steps. Das verfeinerte Visual Glossary benannte Making in HowTo um und fügte Title, Servings, Meal, Diet und ShoppingList hinzu und etablierte die Eindeutigkeitseinschränkung auf Title. Die OpenAPI-Spezifikation definierte all dies als typisierte Schemas mit Einschränkungen. Das React-Frontend renderte es als beschriftete Formularfelder und markierte Badges.

Die Sprache wurde bei jedem Schritt präziser – und genau diese Präzision ist es, was das LLM konsumierte. Wo die Sprache vage war (die Selbstbewertungsregel, die Meal-Recipe-Beziehung), produzierte das LLM vage oder falsche Ausgaben. Wo die Sprache präzise war (die Ingredient-Struktur, die Step-Sequenz), war die Ausgabe bereits beim ersten Prototyp korrekt.

Das ist kein Zufall. Es ist der Mechanismus. Die Ubiquitous Language ist nicht nur ein Kommunikationswerkzeug für menschliche Teams – sie ist die Spezifikation, die LLM-gestützte Entwicklung zuverlässig macht.

---

7. Ein Wort für die Skeptiker

Die berechtigten Bedenken gegenüber LLM-gestützter Entwicklung sind ernst zu nehmen. Modelle halluzinieren. Sie führen subtile Inkonsistenzen ein. Sie können einen falschen Fortschrittseindruck erzeugen, der das Fehlen eines echten Domänenverständnisses verschleiert. Das sind keine theoretischen Risiken – Teams begegnen ihnen regelmäßig.

Das Argument in diesem Beitrag ist nicht, dass diese Risiken verschwinden. Es ist, dass sie erheblich reduziert werden, wenn das Modell innerhalb eines klar definierten Domänenkontexts operiert. Die Selbstbewertungsregel fehlte in Prototyp v1 nicht, weil das LLM unzuverlässig ist, sondern weil das Artefakt unvollständig war. Als die Regel explizit auf einer EventStorming-Richtlinien-Haftnotiz erschien, kodierte das LLM sie korrekt. Das Modell verhielt sich wie ein präziser Ausführer seiner Eingabe – was genau das ist, was es ist.

Was dieser Ansatz nicht ersetzt: Einbindung von Domänenexperten, iterative Verfeinerung, menschliches Urteilsvermögen darüber, was wichtig ist. Die EventStorming-Sitzung, die ShoppingList, Meal und Diet enthüllte, erforderte einen Raum voller Menschen mit Domänenwissen. Das LLM hatte keinen Anteil an dieser Entdeckung. Es hat nur das Ergebnis verarbeitet.

Die Verschiebung, die diese Pipeline vorschlägt, ist nicht „lass das LLM die Domänenarbeit machen". Es ist „mache die Domänenarbeit ordentlich, und das LLM wird ein zuverlässiges Werkzeug für den Rest". Das ist eine bedeutungsvolle und erreichbare Verbesserung gegenüber dem aktuellen Standard, bei dem man vage Beschreibungen an ein Modell übergibt und von vagen Ausgaben überrascht wird.

---

8. Fazit: Stories zuerst, Code danach

Die hier demonstrierte Pipeline ist geradlinig:

Eine Domain Story und ein Visual Glossary geben dem LLM genug Kontext, um einen erkennbaren ersten Prototyp zu produzieren. EventStorming schärft die Sprache, fördert versteckte Regeln zutage und entdeckt fehlende Konzepte – und produziert einen zweiten Prototyp, der messbar vollständiger und korrekter ist. Drei OpenAPI-Spezifikationen, die aus diesen Artefakten abgeleitet werden, kodieren das Ergebnis als maschinenlesbare Verträge, die sowohl die Implementierung als auch die Frontend-Generierung steuern.

Bei jedem Schritt liegt die Investition in der Sprache. Der Code folgt.

Das ist keine neue Idee – es ist das, was spec-getriebene Entwicklung schon immer argumentiert hat. Was neu ist: Die Artefakte, die von kollaborativen Modellierungs-Workshops produziert werden, sind jetzt direkt von LLMs konsumierbar und erzeugen eine enge Rückkopplungsschleife zwischen Domänenerkundung und funktionierender Software. Eine gut moderierte Domain Storytelling-Sitzung ist nicht nur eine Anforderungsaktivität – sie ist der erste Prompt für deinen Prototyp.

Die Frage, die es wert ist, gestellt zu werden, ist nicht „Wie nutzen wir KI, um schneller zu werden?" Es ist „Wie geben wir KI genug Kontext, um in die richtige Richtung zu gehen?" Domain Storytelling und EventStorming waren für menschliche Teams schon immer die Antwort auf diese Frage. Es stellt sich heraus, dass sie auch für LLMs funktionieren.

---

Alle Artefakte, Prompts, OpenAPI-Spezifikationen und generierter Code aus diesem Beitrag sind auf GitHub verfügbar.

Das Larder-Beispiel wurde mit Miro modelliert. Prototypen wurden mit Claude Code generiert.

Referenzen

[1] Hofer, S.; Schwentner, H.: Domain Storytelling - A Collaborative, Visual, and Agile Way to Build Domain-Driven Software, Addison-Wesley Professional, 2021

[2] Brandolini, A.: EventStorming, 2026, abgerufen am 24. Februar 2026, https://www.eventstorming.com/

[3] Evans, E.: Domain-Driven Design - Tackling Complexity in the Heart of Software, Pearson International, 2003

[4] Zörner, S.: Software-Architekturen dokumentieren und kommunizieren: Entwürfe, Entscheidungen und Lösungen nachvollziehbar und wirkungsvoll festhalten, Hanser Fachbuchverlag, 2015

[5] OpenAPI Initiative: OpenAPI Specification 3.1.0, 15. Februar 2021, abgerufen am 24. Februar 2026, https://spec.openapis.org/oas/v3.1.0.html

[6] Garg, R.: When (modular) monolith is the better way to build software, Thoughtworks, 3. Juni 2023, abgerufen am 24. Februar 2026, https://www.thoughtworks.com/en-us/insights/blog/microservices/modular-monolith-better-way-build-software