Der erste Entwurf gewinnt – auch wenn ihn die KI schreibt

Wann KI eine Context Map entwerfen sollte und wann sie sie nur kritisieren sollte

Teil der Serie Domain-Driven Design Meets AI.

In einer Verhandlung geht meist die Seite mit dem besseren Ergebnis nach Hause, die zuerst eine Zahl nennt. Galinsky und Mussweiler haben das in drei Experimenten gezeigt: Das erste Angebot sagte das Verhandlungsergebnis stark voraus (Galinsky & Mussweiler, 2001).

Auch eine Context Map ist eine Verhandlung, selbst wenn niemand im Raum sie so nennt. Und KI hat den ersten Entwurf gerade kostenlos gemacht.

Bevor man also das EventStorming-Board in einen Chat kopiert und nach einer Context Map fragt, lohnt sich eine Frage, die mit KI wenig zu tun hat. Wer sollte den ersten Entwurf mitbringen, und was passiert mit der Diskussion, sobald er auf dem Tisch liegt?

Eine Landkarte des Einflusses, nicht der Daten

Frühere Beiträge dieser Serie haben Bounded Contexts gefunden: in Domain Stories, auf dem EventStorming-Board und in den Pivotal Events, an denen die Verantwortung von einer Hand in die nächste übergeht. Was diese Techniken nicht zeigen: wie die Contexts voneinander abhängen, sobald sie gebaut sind.

Das ist die Aufgabe der Context Map (Evans, 2003). Jeder Bounded Context erscheint darin genau einmal, und die Pfeile zeigen, wer von wem abhängt.

Upstream und Downstream werden leicht missverstanden. Sie beschreiben nicht die Richtung der Daten. Sie beschreiben die Richtung des Einflusses: Das Upstream-Team kann sein Modell ändern, ohne zu fragen, und das Downstream-Team muss folgen (DDD Crew, 2020).

Für jeden Pfeil wählen die Teams ein Muster. Der Upstream-Context kann einen Open Host Service anbieten, ein dokumentiertes Protokoll für alle Konsumenten. Der Downstream-Context kann sein eigenes Modell hinter einem Anti-Corruption Layer schützen oder das Upstream-Modell als Conformist einfach übernehmen. In einer Customer/Supplier-Beziehung hat das Downstream-Team ein Mitspracherecht bei dem, was es bekommt. Zwei Contexts können sich einen Shared Kernel teilen oder Separate Ways gehen (Evans, 2003, 2015).

Wenn niemand diese Fragen ausdrücklich beantwortet, beantwortet sie die erste Integration – und zwar zufällig.

Warum sich die Diskussion im Kreis dreht

Die Muster auszuwählen ist mühsam, und die Diskussion dreht sich gern im Kreis. Das liegt nicht an einem unerfahrenen Team. Die Muster schließen einander nicht aus, sondern lassen sich kombinieren, und die Literatur ist sich nicht einig, wie (DDD Crew, 2020; Kapferer & Zimmermann, 2020). Schlimmer noch: Eigentlich geht es darum, welches Team Einfluss auf welches andere hat. Eine Context Map zeigt immer auch, wie die Politik gespielt wird (DDD Crew, 2020).

Für solche Fragen ist die offene Diskussion ein schwaches Instrument. In einer klassischen Studie zu strategischen Entscheidungen kamen Gruppen, die auf Konsens hinarbeiteten, zu schlechteren Empfehlungen als Gruppen, die unter strukturiertem Widerspruch arbeiteten, etwa mit einem Advocatus Diaboli. Zugleich waren die Konsensgruppen mit ihrem Ergebnis zufriedener (Schweiger et al., 1986).

In genau dieser Lage geben wir das Problem jetzt an eine KI.

Was für einen KI-Entwurf spricht

Ein Entwurf gibt einer festgefahrenen Diskussion etwas, worauf sie reagieren kann. In einem Online-Experiment schrieben Autorinnen und Autoren, die Story-Ideen von einem LLM erhielten, Geschichten, die als kreativer, besser geschrieben und unterhaltsamer bewertet wurden – und am meisten profitierten die am wenigsten Kreativen (Doshi & Hauser, 2024).

Auf etwas zu reagieren ist leichter, als auf eine leere Wand zu starren. KI als Design-Partner hat diese Rolle den Entwerfer genannt, und bei einer Context Map liegt es nahe, ihn einzusetzen.

Der Preis eines Entwurfs

Dasselbe Experiment ergab, dass die KI-gestützten Geschichten einander ähnlicher waren (Doshi & Hauser, 2024). In einer Nutzerstudie zur kreativen Ideenfindung brachten Menschen, die mit ChatGPT arbeiteten, als Gruppe einheitlichere Ideen hervor, und sie fühlten sich für ihre eigenen Ideen weniger verantwortlich (Anderson et al., 2024).

Ein Entwurf setzt einen Anker. Alle bewegen sich auf ihn zu, und niemandem gehört er so richtig.

Dazu kommt ein zweiter Haken, und der betrifft speziell Context Maps. Ein aktueller Preprint ließ ein LLM Microservice-Architekturen aus textuellen Anforderungen für zwei kleine Systeme ableiten. Die Services erkannte es gut, mit F1-Werten zwischen 0,79 und 0,97. Die Interaktionen zwischen den Services fielen ihm schwerer: F1 zwischen 0,61 und 0,82, und ohne Beispiele im Prompt war weniger als die Hälfte der vorgeschlagenen Abhängigkeiten korrekt (Albuquerque et al., 2026). Die Pfeile sind die Schwachstelle – und um die Pfeile geht es in einer Context Map.

Was passierte, als die KI unsere Map entwarf

Das durchgängige Beispiel des Buchs ist Larder, eine Rezeptplattform, auf der Köchinnen und Köche beim Planen oder Kochen einen Grandma Avatar, einen Profikoch (Chef) oder die Community um Hilfe bitten können. Wir haben das EventStorming-Board einer KI mit einem Context-Mapping-Skill gegeben und um eine Map gebeten (vollständiger Chat).

Die Context Map, die die KI aus dem EventStorming-Board entworfen hat. Die gepunkteten Pfeile markieren die Lücken, die sie gefunden hat.

Der Entwurf wirkte gründlich. Jeder Pfeil trug ein Muster, und die KI markierte sieben Lücken: Stellen, an denen ihrer Ansicht nach Information eine Grenze überqueren müsste, aber nichts auf dem Board sie transportierte.

Einige dieser Lücken waren echt, und das Team schloss sie mit neuen Pfeilen. Viele waren nicht das, wonach sie aussahen.

• Nothing reads Cook („niemand liest den Koch”) war keine Lücke. Die Identität des Kochs reist als JWT im Header jedes synchronen Aufrufs mit. Das ist ein Architekturprinzip, und Architekturprinzipien stehen nicht auf einem EventStorming-Board.
• Nobody is told a request exists („niemand erfährt von der Anfrage”) war echt, aber die Antwort war ein Notification-Context, den noch niemand gezeichnet hatte.
• Nothing identifies the meal („nichts identifiziert die Mahlzeit”) hat die Domäne missverstanden. Die Mahlzeit existiert auf dem Herd, nicht in der App. Sie wird über das Rezept und den Koch identifiziert.

Auch die Muster änderten sich. Die KI hatte die meisten Pfeile mit Customer/Supplier oder Conformist beschriftet. Das Team ersetzte fast alle durch Open Host Service und einigte sich auf API Contract First, sodass jedes Team gegen eine dokumentierte Schnittstelle baut und releasen kann, ohne auf seine Konsumenten zu warten.

Die Überarbeitung war mühsam. Fast jede Korrektur beruhte auf Wissen, das nicht auf dem Board stand, oder auf einem Missverständnis dessen, was dort stand. Die KI konnte es nicht besser wissen. Aber die Diskussion bestand jetzt darin, das Bild eines anderen zu korrigieren, statt unser eigenes zu zeichnen.

Was passierte, als das Team zuerst zeichnete

Also haben wir es andersherum versucht. Das Team leitete die Map selbst aus dem Board ab, ein Rechteck pro Bounded Context, und diskutierte jede Abhängigkeit.

Beim Zeichnen kam zum Vorschein, was das Board nicht gezeigt hatte. Rezepte brauchten einen Besitzer, also führte das Team einen Recipe Catalog ein. Bei der Frage, wie sich ein Koch bei den Helfenden bedankt, merkte das Team, dass Helfende zustimmen müssen, bevor sie namentlich genannt werden – so entstand Consent Management. Irgendjemand muss der Community oder dem Profikoch Bescheid geben, dass eine Anfrage wartet – so kam Notification hinzu. Der Grandma Avatar wurde zu einem externen Prozess hinter einem Anti-Corruption Layer.

Dann bekam die KI das Board und die Map des Teams mit genau einem Auftrag: die Stellen finden, an denen die Map etwas behauptet, das die Klebezettel nicht stützen (Konsistenz-Skill).

Ihr schärfster Befund betraf ein einziges Wort. Die Map ordnete Ingredients dem Recipe Catalog zu. Auf dem Board schreibt aber Meal Planning die Zutaten, wenn eine Köchin eine davon ersetzt, und Cooking Assistance liest sie. Die KI vermutete zwei verschiedene Dinge unter einem Wort – die Zutatenliste eines Rezepts und die Liste dieser einen Köchin für das heutige Abendessen – und schlug eine Frage vor, die das klären würde:

Wenn eine Köchin Pinienkerne durch Walnüsse ersetzt, ändert das irgendetwas im Katalog?

Wenn nicht, sind es zwei Begriffe. Das Team neigte dazu, das Wort zu behalten, denn das Visual Glossary sagt bereits, dass ein Ersatz eine Zutat ist, und jeder Context kann mit seiner eigenen Bedeutung leben. Ob die KI recht hatte, ist weniger wichtig als das, was ihre Frage bewirkt hat. Aus einer Annahme wurde eine Entscheidung.

Die Regel

Wenn die Teams einander leicht erreichen, zeichnen sie die Map selbst, und die KI übernimmt die Rolle des Kritikers. Das Gespräch erzeugt die Verbindlichkeit (Evans, 2015), und das Review findet, worauf sich der Raum zu schnell geeinigt hat. Die Verantwortung bleibt bei denen, die mit den Pfeilen leben müssen.

Wenn sie das nicht können, darf die KI entwerfen – aber wer den Entwurf mitbringt, setzt den Anker. Verschiedene Unternehmen, ein Dienstleister und sein Kunde, Kommunikation über Verträge und angesetzte Termine: Hier ist der Weg über die Verhandlung am Tisch versperrt. Selbst Consumer-Driven Contracts setzen voraus, dass Konsumenten dem Provider sagen können, was sie brauchen (Robinson, 2006). Ein KI-Entwurf gibt beiden Seiten ein konkretes Artefakt, auf das sie reagieren können, statt einer Workshop-Reihe, die niemand bezahlen kann.

Doch ein Entwurf, der über eine Organisationsgrenze hinweg mitgebracht wird, ist nicht neutral. Wer ihn mitbringt, setzt den Anker, zumindest dort, wo beide Seiten die Frage als Nullsummenspiel betrachten (Galinsky & Mussweiler, 2001). Man sollte damit rechnen, dass die fertige Map näher am eigenen Entwurf landet als an der Sicht des Gegenübers – und dass das Gegenüber es merkt. Es lohnt sich, jemandem ausdrücklich die Aufgabe zu geben, für ein anderes Muster zu argumentieren (Schweiger et al., 1986). Und wer den Entwurf empfängt, findet in derselben Forschung das Gegenmittel: Der Anker verlor seine Wirkung, wenn sich die Verhandelnden auf ihr eigenes Ziel und auf die Alternativen der Gegenseite konzentrierten (Galinsky & Mussweiler, 2001).

Entwerfen, was bekannt ist – kritisieren, was vereinbart werden muss

Nachdem die Map vereinbart war, brauchte das Team für jeden Context ein Bounded Context Canvas (DDD Crew, 2019). Ein Canvas sammelt größtenteils, was es schon gibt: in der Context Map, auf dem EventStorming-Board und im Visual Glossary. Genau solche Arbeit kann man abgeben, und die KI hat mit einem Canvas-Skill alle Canvases entworfen. Das Ergebnis brauchte nur kleine Anpassungen.

Nebeneinandergelegt ergeben beide Erfahrungen eine Regel, die über Context Maps hinausreicht. Die KI soll entwerfen, was das Team schon weiß. Sie soll kritisieren, worauf sich das Team erst noch einigen muss.

KI hat den ersten Entwurf kostenlos gemacht. Neutral hat sie ihn nicht gemacht.

Als Nächstes in dieser Serie: Das Wort, das alles kaputt macht — warum die Ubiquitous Language schon ab dem ersten Tag der Implementierung driftet und warum KI einen guten Schiedsrichter zwischen Domain Stories, Visual Glossary und API-Schema abgibt.

Diese Serie ist aus meiner Arbeit am Buch DDD Meets AI entstanden, das im Februar 2027 bei Springer Nature erscheint.

---

Referenzen

Albuquerque, D., Renan, J., Rodríguez, G., Díaz-Pace, J. A., Dantas, E., França, A., Perkusich, M., Gorgônio, K., & Perkusich, A. (2026). From textual requirements to microservice architectures: A comprehensive evaluation of LLM-based design synthesis. arXiv preprint arXiv:2607.28307v1. https://arxiv.org/abs/2607.28307

Anderson, B. R., Shah, J. H., & Kreminski, M. (2024). Homogenization effects of large language models on human creative ideation. Proceedings of the 16th Conference on Creativity & Cognition (c&c ’24), 413–425. https://doi.org/10.1145/3635636.3656204

DDD Crew. (2019). Bounded context canvas. GitHub repository, ddd-crew/bounded-context-canvas. https://github.com/ddd-crew/bounded-context-canvas

DDD Crew. (2020). Context mapping. GitHub repository, ddd-crew/context-mapping. https://github.com/ddd-crew/context-mapping

Doshi, A. R., & Hauser, O. P. (2024). Generative AI enhances individual creativity but reduces the collective diversity of novel content. Science Advances, 10(28), eadn5290. https://doi.org/10.1126/sciadv.adn5290

Evans, E. (2003). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley.

Evans, E. (2015). Domain-driven design reference: Definitions and pattern summaries. Dog Ear Publishing.

Galinsky, A. D., & Mussweiler, T. (2001). First offers as anchors: The role of perspective-taking and negotiator focus. Journal of Personality and Social Psychology, 81(4), 657–669. https://doi.org/10.1037/0022-3514.81.4.657

Kapferer, S., & Zimmermann, O. (2020). Domain-specific language and tools for strategic domain-driven design, context mapping and bounded context modeling. Proceedings of the 8th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2020), 299–306. https://doi.org/10.5220/0008910502990306

Robinson, I. (2006). Consumer-driven contracts: A service evolution pattern. martinfowler.com. https://martinfowler.com/articles/consumerDrivenContracts.html

Schweiger, D. M., Sandberg, W. R., & Ragan, J. W. (1986). Group approaches for improving strategic decision making: A comparative analysis of dialectical inquiry, devil’s advocacy, and consensus. Academy of Management Journal, 29(1), 51–71. https://doi.org/10.5465/255859