Domain Driven Kitchen Madness: Wie ein Pasta‑Abend uns lehrt, Domänen zu schneiden statt nur Gemüse

Ein ungewöhnlicher Einstieg in Domain-driven Design

Bei „Domain Driven Kitchen Madness“ zeigte Maurizio Rinder (SQUER) eindrücklich, wie man Domänen nicht nur in Softwareprojekten, sondern sogar in einer Küche schneidet. Der Talk ist bewusst leicht auf Entwickler-Folien, dafür schwer auf Denkarbeit: Statt Frameworks oder Code gab es eine erzählerische, aber präzise Reise durch Problem- und Lösungsraum, Double Diamond, Subdomänen, Kern-Domäne, Bounded Contexts und Teamzuschnitt – alles anhand eines einfachen, greifbaren Ziels: „Ich koche meinen Freund:innen eine Pasta, die sie nicht ablehnen können.“

Als Redaktion von DevJobs.at haben wir die Session als bewusst „taktlos“ in Sachen Code erlebt – aber genau darin lag die Stärke: klares Denken, gemeinsame Sprache, gezielte Investition der Energie in das, was differenziert. Dieser Artikel rekonstruiert die Leitideen und hält fest, wie Engineering-Teams sie morgen in der Praxis anwenden können.

Vom „Cutting Ninja“ zur gemeinsamen Problemdefinition

Maurizios Einstieg: Nur weil jemand Gemüse in Sekunden perfekt würfeln kann, bedeutet das noch nicht, dass daraus ein gutes Gericht entsteht. In Software übersetzt: Wir können hochperformante Microservices bauen – und landen dennoch bei der „Microservice-Death-Star“-Architektur und Features ohne Kundennutzen, weil wir die falschen Probleme lösen. Die Pointe: Ohne Big Picture sind „Skills“ wertlos.

Genau hier setzt Domain-driven Design (DDD) an – nicht als Architekturpattern, sondern als Designansatz, der Geschäftsverständnis und Software miteinander synchronisiert. Zentral ist die bewusste Unterscheidung von Problemraum und Lösungsraum, idealtypisch im Double-Diamond-Modell gedacht.

Double Diamond: Problemraum und Lösungsraum im Loop

Maurizio teilt den Weg in zwei sich wiederholende Phasen:

• Entdecken (Problemraum): Verstehen, was das eigentliche Problem ist, wer betroffen ist, welche Ziele wirklich zählen. Breite Exploration, danach Fokussierung. Strategisches DDD lebt hier.
• Entwickeln (Lösungsraum): Erste Lösungsversion schnell liefern, Feedback einholen, iterieren. Taktisches DDD wirkt hier.

Wichtig: Es ist kein One-Shot-Prozess. Loops sind normal und gewollt, weil sich Verständnis, Sprache und Domäne mit der Zeit weiterentwickeln. Der größte Hebel? Gemeinsames Vokabular und Empathie. Wer die Sprache des Business spricht, stellt bessere Fragen und trifft bessere Entscheidungen.

Produktvision: Das Zielbild des Pasta-Abends

Die Anekdote: Nach zwei, drei Negronis im Freundeskreis – das Versprechen, ein unvergessliches Pasta-Dinner zu kochen. Am nächsten Morgen steht der Termin im Kalender. Panik wäre naheliegend, doch der Talk zeigt, wie man mit DDD Ruhe reinbringt – beginnend mit einer Produktvision.

Maurizios „Product Vision Board“ für den Abend (frei nach seiner Gliederung):

• Vision: „Ich mache meinen Freund:innen eine Pasta, die sie nicht ablehnen können.“
• Zielgruppe: Die eigenen Freund:innen – insbesondere jene, die italienische Küche bisher als repetitiv erlebt haben.
• „Needs“ (Probleme): Immer die gleiche Pasta-Tomatensoße-Erfahrung, langweilig, wenig Varianz.
• Produktidee: Eine harmonisch kombinierte Pasta mit passender Soße, Getränkeauswahl und italienischem Flair.
• Geschäftsziel (Übertrag ins Produktdenken): Retention und Word-of-Mouth – die Gäste sollen wiederkommen und davon erzählen.

Dass ein Product Vision Board Zeit kostet (Workshop-Format, u. U. 2–3 Stunden), betont Maurizio ausdrücklich. Es ist eine Investition in Klarheit und Ausrichtung.

Ein kleiner, aber wichtiger Zusatz aus der Praxis: Präferenzen vorher erfragen. In der Küche (und im Projekt) ist es fatal, stundenlang ein Ragù zu kochen, um am Ende zu erfahren, dass die Gäste vegetarisch sind. Übertragen heißt das: Stakeholder-Fragen, Erwartungsklärung, Kontexte sauber abholen.

Domänen entdecken: Mit den richtigen Fragen zur richtigen Granularität

Discovery beginnt nicht mit Tools, sondern mit Menschen. Domain-Expert:innen sind die Quelle – in seiner Geschichte: die Mutter. Maurizio nutzt „Domain Storytelling“, um den Ablauf als Geschichte mit Akteur:innen und Artefakten zu erfassen. Wichtig ist die Fragetechnik: Eine zu breite Frage („Wie koche ich perfekte Pasta?“) führt zu Tagen voller Detail, aber ohne Ergebnis. Eine zielgerichtete Frage („Wie organisiere ich ein schönes Abendessen für meine Gäste?“) liefert die passende Granularität.

Aus dem Gespräch entsteht eine verständliche Prozessgeschichte:

• Menü planen
• Zutaten ableiten und Einkaufszettel erstellen
• Einkaufen
• Kochen (inkl. Pasta-Soßen-Paarung)
• Musik an, Tisch dekorieren
• Getränke passend wählen (Rotwein/Weißwein – je nach Sauce)
• Final: Espresso oder Espresso Macchiato (kein Cappuccino am Abend)

Als ergänzende Discovery-Techniken erwähnt Maurizio: Event Storming (großes Bild, auch für Teilprozesse), Example Mapping (mit „guten Beispielen“ 80 % der Fälle abdecken). Alle sind zeitintensiv – aber liefern eine starke gemeinsame Grundlage.

Subdomänen schneiden: Kognitive Last reduzieren, Verantwortung klären

Aus der Story heraus lassen sich Übergaben („Handovers“) erkennen – ein Indikator für sinnvolle Schnittstellen:

• Menüplanung
• Kochen & Zutaten (bewusst gekoppelt, da Zutatenqualität/‑wahl eng mit dem Kochprozess verknüpft ist)
• Einkauf
• Musik
• Dekoration
• Getränke

Warum diese Zerlegung? Weil sie kognitive Last reduziert und Autonomie schafft. Teams (oder Personen) können einen Bereich fokussiert verantworten. Wie in jeder professionellen Küche gibt es Stationen – warum nicht auch in Software?

Strategische Priorisierung: Core Domain Chart

Nicht jeder Bereich ist gleich wichtig. Mit dem Core Domain Chart (X: Business-Differenzierung/USP, Y: Komplexität) ordnet Maurizio die Subdomänen ein:

• Kern-Domäne (hoch differenzierend, relevante Komplexität): Kochen & Zutaten. Genau hier liegt die Erfahrung, die die Gäste behalten sollen.
• Unterstützend: Menüplanung, Einkauf. Notwendig, aber nicht das Alleinstellungsmerkmal.
• Generisch: Getränke, Musik, Dekoration. Wichtig fürs Erlebnis, aber typischerweise „zukaufbar“/standardisierbar.

Spannend: Prioritäten sind dynamisch. Beim nächsten Dinner könnte „Einkauf“ in Richtung Kern rücken – etwa wenn statt Supermarkt bewusste Qualität (z. B. Wochenmarkt) den Unterschied macht. Das vermittelt: Investitionen folgen dem, was tatsächlich differenziert.

Vom Subdomänenschnitt zur Kontextkarte

Subdomänen sind Business-Sicht. Bounded Contexts sind die Lösungssicht – oft 1:1, aber nicht zwingend. Entscheidend ist, Beziehungen und Abhängigkeiten explizit zu machen:

• Menüplanung ↔ Kochen & Zutaten: Das geplante Menü prägt Rezepturen, Zutatenliste und Kochschritte.
• Zutaten → Einkauf: Was gebraucht wird, bestimmt, wie und wo gekauft wird.
• Getränke ↔ Menüplanung: Sauce und Wein gehören zusammen (Rot/Weiß je nach Gericht).
• Dekoration: Weitgehend unabhängig, vielleicht lose abgestimmt auf das Menü.

Diese Kontextsicht erlaubt Teamautonomie mit minimaler Koordination an den Schnittstellen.

Teamzuschnitt: Zwei Squads, klare Missionen

Maurizio übersetzt die Karte in eine einfache Team-Topologie:

• Squad „Vaffale“: Verantwortlich für das Kocherlebnis – von der Menüplanung über Einkauf bis zum Kochen.
• Squad „Barolo“: Verantwortlich für den „Italian Vibe“ – Musik, Dekoration, Getränke.

Die Koordinationslast ist niedrig: „Barolo“ braucht im Wesentlichen das Menü als Input. Danach arbeiten beide unabhängig. Der Hinweis auf das Buch „Team Topologies“ unterstreicht: Sichtbare Teaminteraktionen und klare Servicegrenzen steigern Geschwindigkeit und Qualität.

Was DDD im Alltag bringt: Empathie, Sprache, bessere Entscheidungen

Maurizio nennt mehrere Effekte, die wir in Projekten regelmäßig sehen:

• Gemeinsames Vokabular: Weniger Missverständnisse, schnelleres Onboarding, klarere Diskussionen.
• Empathie: Entwickler:innen stellen bessere Fragen – nicht „Welche Datenbank?“ sondern „Welches Problem ist zu lösen?“.
• Ausrichtung: Implementierungen folgen nachgelagert der Businesslogik, nicht umgekehrt.
• Anpassungsfähigkeit: Wenn das Business sich bewegt, kann die Lösung sich gezielter mitbewegen.

Und vor allem: Wir vermeiden, „random Stuff zu bauen“, Features ohne Nutzen oder überzogene Architekturvehikel.

Iteration vor Perfektion: Feedback früh ermöglichen

Zum Double Diamond gehört, früh etwas Nutzbares zu liefern – selbst wenn es nur knapp über Prototypenniveau liegt. Feedback senkt Risiko: „Perfekt“ ist in komplexen Domänen ohnehin eine Fata Morgana. Iteration ist der Weg.

Ein bewusst „analoges“ Beispiel – und wo Digitales sinnvoll wäre

Die Dinner-Story ist absichtlich „analog“ modelliert: Keine Tools, keine Apps, nur Domäne. Genau das macht den Denkrahmen übertragbar. Gegen Ende streut Maurizio bewusst einen Denkanstoß: Wo könnte digitale Unterstützung Sinn ergeben? Sein Beispiel: Menüplanung – etwa um Lebensmittelverschwendung zu vermeiden, indem man Menüs so plant, dass Zutaten über die Woche hinweg aufgebraucht werden.

Wichtig ist die Reihenfolge: Erst Domäne verstehen, dann über Digitalisierung sprechen – nicht umgekehrt.

Praktische Leitfragen für den Projektalltag

Wir haben aus dem Talk folgende Leitfragen destilliert, die in jedem Projekt helfen:

1. Problemraum vor Lösungsraum: Welche Probleme lösen wir – für wen, warum gerade jetzt?
2. Gemeinsame Sprache: Welche Begriffe verwenden Stakeholder wirklich? Welche Beispiele decken 80 % ab?
3. Subdomänen & Bounded Contexts: Wo sind natürliche Übergaben? Welche Beziehungen sind kritisch?
4. Kern vs. unterstützend vs. generisch: Wo entsteht unser USP? Wo kaufen wir besser zu?
5. Teamzuschnitt: Wie minimieren wir Koordination und maximieren Autonomie entlang der Kontexte?
6. Iteration: Was ist das kleinste Sinnvolle, um Feedback zu bekommen?
7. Erwartungen managen: Welche Präferenzen müssen wir früh klären (die „Vegetarier:in-im-Ragù“-Falle)?

Konkrete Anwendungsschritte (ohne Tool-Overkill)

• Kurzer Vision-Workshop: 2–3 Stunden für Zielbild, Zielgruppe, Probleme, Produktidee, Geschäftsziel.
• Discovery-Session mit Domain-Expert:innen: Fragen auf die richtige Granularität zuspitzen; Domain Storytelling nutzen.
• Optional: Event Storming für das Big Picture, Example Mapping für typische Fälle.
• Subdomänen identifizieren: An Handovers und Verantwortungsübergängen orientieren.
• Core Domain Chart: Investitionsentscheidungen bewusst machen und transparent halten.
• Kontextkarte: Abhängigkeiten sichtbar machen und Teams entsprechend zuschneiden.
• Erste Inkremente liefern: Früh Feedback holen, Iterationsschleife schließen.

Zitate und Gedankenstützen aus dem Talk

• „DDD ist eine Software-Design-Ansatz, keine Architekturschablone.“
• „Welche Probleme wollen wir mit X lösen?“ – die wichtigste Frage in jedem Meeting.
• „Cappuccino ist für Tourist:innen und Frühstück“ – als Metapher für: Kontext zählt.
• „Ich mache euch eine Pasta, die ihr nicht ablehnen könnt“ – Visionen dürfen emotional sein, solange sie Handeln ausrichten.

Quellen, die Maurizio genannt hat

• DDD-Crew-Wiki mit einem „Startup Modeling Process“
• Bücher: Eric Evans, ein Buch von Vlad Kononov, „Domain-driven Transformation“
• „Team Topologies“ als Referenz für Teamstruktur und -interaktionen
• Como Camp (Unconference), als Ort für Austausch und Lernen

Fazit: Domänen schneiden, nicht nur Services

„Domain Driven Kitchen Madness“ zeigt, wie mächtig es ist, zuerst Sprache und Verantwortung zu schneiden – erst dann Architektur. Wer die Kern-Domäne bewusst wählt, reduziert Overengineering und maximiert Wirkung. Und wer die richtigen Fragen stellt, kocht am Ende nicht nur bessere Pasta – er liefert Software, die sich am echten Problem orientiert.

Quick-Checklist für Teams

• Definiert euer „Warum“ (Vision, Zielgruppe, Problem, Outcome).
• Sprecht mit Domain-Expert:innen und nutzt Domain Storytelling.
• Schneidet Subdomänen anhand natürlicher Übergaben.
• Entscheidet mit dem Core Domain Chart, wo ihr bewusst investiert.
• Modelliert Bounded Contexts und minimiert Teamabhängigkeiten.
• Liefert früh, lernt schnell, iteriert bewusst.
• Fragt in jedem Refinement: „Welches Problem lösen wir damit?“

• 

  

  Architecting for Scale

  David Leitner von SQUER spricht in seinem TechTalk über die auftretenden Challenges – technologisch und organisatorisch – wenn ein System skaliert und wie damit umgegangen werden kann.

  Jetzt ansehen

• 

  

  David Leitner, Co-Founder von SQUER

  David Leitner von SQUER gibt im Interview Einblicke in die Arbeitsweise der Developer im Unternehmen, auf was beim Recruiting geachtet wird und spricht über die verwendeten Technologien.

  Jetzt ansehen

• 

  

  Julia Toifl, Senior Full Stack Engineer bei SQUER

  Julia Toifl von SQUER spricht in ihrem Interview über ihren unerwarteten Einstieg in die IT als Physikerin, was die aktuelle Arbeit im Full Stack Engineering umfasst und gibt Tipps für Neueinsteiger.

  Jetzt ansehen