Domain Driven Kitchen Madness: From Negroni Dares to Bounded Contexts — Our Engineering Recap of Maurizio Rinder’s DDD Story

Why this talk stood out

In “Domain Driven Kitchen Madness,” Maurizio Rinder (SQUER) traded code for clarity. No frameworks, no live coding — instead, a crisp, memorable narrative that anchored Domain-driven Design (DDD) in a kitchen. The result was a rare kind of engineering session: highly practical without being tool-heavy, and laser-focused on aligning teams around problem space, language, and responsibility.

As DevJobs.at editors, we found the simplicity disarming and the substance compelling. Below we unpack the core ideas and translate them into concrete steps teams can apply right away.

From cutting prowess to problem clarity

Maurizio opened with a tongue-in-cheek analogy: being a “cutting ninja” in the kitchen doesn’t guarantee a great dish. In software terms, raw technical skill can still produce a “microservice death star,” or features nobody needs, when we don’t share a big picture or miss undiscovered customer needs. Skill without domain alignment doesn’t ship value.

DDD addresses exactly this — not as an architecture pattern, but as a software design approach that synchronizes business understanding and software. And the key move is distinguishing problem space from solution space, using the Double Diamond as a mental model.

The Double Diamond: discover, define, build, refine — in loops

Maurizio mapped the journey into two repeating halves:

• Discover and define (problem space): Learn what the real problem is, who it affects, which outcomes matter. Explore broadly, then narrow focus. This is where strategic DDD lives.
• Develop and deliver (solution space): Ship an early, imperfect version to get feedback quickly. Iterate. This is where tactical DDD lives.

Crucially, it’s not a one-off path. Loops are intentional because complex domains evolve — language changes, boundaries shift, and understanding deepens with feedback. The payoff: a shared vocabulary and empathy across roles, which leads to sharper questions and better decisions.

The kitchen story: a promise becomes a product vision

The story: after a few Negronis with friends, Maurizio promised to cook “a pasta they can’t refuse.” The next morning, the calendar reminder made it real. Rather than panic, he applied DDD, starting with a lean product vision.

He framed a Product Vision Board along these lines:

• Vision: “I’m going to make my friends a pasta they can’t refuse.”
• Target group: his friends, especially those who find restaurant pasta repetitive and boring.
• Needs (problems): the same tomato-sauce routine, little variation, little delight.
• Product idea: a pasta well matched with its sauce, plus the right beverages to create an Italian vibe.
• Business goal (translated to product terms): retention and sharing — they should want to come back and tell others.

He also called out the time investment: a Product Vision Board is a workshop, not a quick form. Two to three hours can be reasonable — because clarity is a form of speed.

One practical reminder from the kitchen that holds in software: ask for preferences early. Don’t slow-cook a meat ragù only to discover your guests are vegetarians. Translate that to product: check assumptions, confirm constraints, and clarify expectations.

Discovery: talk to domain experts and ask at the right granularity

Discovery starts with people. In this story, the domain expert was his mother. Maurizio used Domain Storytelling to capture the process, but emphasized that question scope determines the usefulness of what you learn. “How do I cook perfect pasta?” explodes into days of detail. “How do I organize a nice dinner for my guests?” yields just enough granularity to act.

From that conversation, the domain narrative looked like:

• Plan the menu
• Derive ingredients and create a shopping list
• Go shopping
• Cook (and pair pasta shapes/sauces appropriately)
• Turn on music, decorate the table
• Choose beverages that fit (red/white, depending on the sauce)
• Finish with an espresso or espresso macchiato (no cappuccino in the evening)

As additional techniques for discovery, Maurizio mentioned Event Storming (big-picture modeling, also usable for smaller processes) and Example Mapping (cover 80% of cases with concrete examples). All require real workshop time — discovery is an investment.

Subdomain decomposition: lower cognitive load, raise autonomy

From the Domain Storytelling map, handovers signal natural seams. The resulting subdomains:

• Menu planning
• Cooking & ingredients (intentionally coupled, because ingredient quality and selection co-evolve with cooking)
• Shopping
• Music
• Decoration
• Beverages

Why decompose? To reduce cognitive load and establish clear responsibility. Just like stations in a professional kitchen, teams (or individuals) can own a subdomain end-to-end.

Strategy with a Core Domain Chart: where to invest brainpower

Not every subdomain deserves equal attention. Using a Core Domain Chart (X-axis: business differentiation/USP, Y-axis: complexity), Maurizio placed each subdomain:

• Core domain (differentiating, non-trivial complexity): Cooking & ingredients. This is the experience guests will remember.
• Supporting: Menu planning and shopping. Necessary, but not the differentiator.
• Generic: Beverages, music, decoration. Important to the evening, but typically commodity.

He also highlighted that priorities can shift. Next time, “shopping” might push toward core if quality sourcing (say, a farmer’s market instead of a supermarket) becomes a differentiator. The lesson: invest where differentiation grows.

From subdomains to bounded contexts and relationships

Subdomains express the business view; bounded contexts define solution boundaries. Often they map 1:1, but not always. What matters is to make relationships explicit:

• Menu planning ↔ Cooking & ingredients: the planned menu constrains recipes, ingredients, and cooking.
• Ingredients → Shopping: needs drive procurement.
• Beverages ↔ Menu planning: sauce type influences wine pairing (red/white).
• Decoration: largely independent; perhaps loosely aligned with the menu.

This context map enables team autonomy with minimal coordination at well-defined interfaces.

Team topology: two squads, clear missions

Maurizio translated that map into two squads:

• Squad “Vaffale”: end-to-end for the cooking experience — menu planning through shopping to cooking.
• Squad “Barolo”: responsible for the Italian vibe — music, decoration, beverages.

Coordination is light: “Barolo” mainly needs the menu as input; then both squads can operate independently. The nod to the “Team Topologies” book underscores how explicit team interactions and boundaries improve flow.

What DDD gives teams: empathy, vocabulary, and better choices

Recurring benefits Maurizio called out — and we routinely see in practice:

• Shared language: fewer misunderstandings, faster onboarding, cleaner debates.
• Empathy: developers ask better questions — not “Which database?” but “Which problem?”
• Alignment: implementation follows business logic rather than arbitrary tech preferences.
• Adaptability: when business shifts, the solution can evolve along the right seams.

And crucially: we avoid building “random stuff,” or the kind of overengineered architectures that impress on paper but fail users.

Iteration over perfection: ship early, learn fast

The Double Diamond expects an early, imperfect increment — just enough to solicit feedback. In complex domains, “perfect” is a mirage; iteration is the mechanism of learning.

An intentionally analog story — and where digital might help

Maurizio emphasized that the dinner narrative is “pure story”: no computers, no tools, just the domain. That’s deliberate. Only after understanding the domain does it make sense to ask: where could digital assistance add value? He suggested one candidate: menu planning, potentially to reduce food waste by planning menus so ingredients get fully used across the week.

The ordering matters: understand first, digitize second.

Field guide questions for everyday projects

We distilled a set of questions from the talk that travel well across domains:

1. Problem space before solution space: Which problem, for whom, and why now?
2. Shared language: What words do stakeholders actually use? Which examples cover 80% of cases?
3. Subdomains and bounded contexts: Where are the natural handovers? Which relationships are critical?
4. Core vs. supporting vs. generic: Where is our USP? Where should we buy/commoditize?
5. Team design: How do we minimize coordination and maximize autonomy along context boundaries?
6. Iteration: What’s the smallest valuable increment to get feedback?
7. Expectation checks: Which “preferences” must we clarify early (avoid the ragù-for-vegetarians trap)?

A pragmatic playbook (no tool fetish required)

• Run a compact vision workshop: 2–3 hours for vision, target group, problems, product idea, and expected outcomes.
• Do discovery with domain experts: tune the questions for the right granularity; use Domain Storytelling to capture the flow.
• Optionally apply Event Storming for the big picture and Example Mapping for typical cases.
• Identify subdomains: use handovers and responsibility shifts as natural seams.
• Build a Core Domain Chart: make investment decisions explicit.
• Draft a context map: make dependencies explicit and shape teams accordingly.
• Deliver an early increment: get feedback, close the loop, iterate.

Memorable lines to keep on the wall

• “DDD is a software design approach, not an architecture pattern.”
• “What problem do we want to solve with that?” — ask it in every refinement.
• “Cappuccino is for tourists and breakfast” — context matters; the right thing, in the right place.
• “I’m going to make my friends a pasta they can’t refuse” — visions can be emotional if they drive action.

Sources Maurizio pointed to

• The DDD crew wiki with a “startup modeling process”
• Books by Eric Evans, a book by Vlad Kononov, and “Domain-driven Transformation”
• Team Topologies (as a shared language for team interactions)
• Como Camp (an unconference) as a place for learning and conversation

Closing: cut domains before you cut services

“Domain Driven Kitchen Madness” makes a simple point unforgettable: slice the domain and the language first, then slice the architecture. Choose your core domain deliberately, and you’ll avoid overengineering while maximizing impact. Ask better questions, and both pasta and software will taste better.

Monday-morning checklist for engineers

• Define the “why” (vision, audience, problem, outcomes).
• Talk to domain experts and capture the narrative with Domain Storytelling.
• Slice subdomains along natural handovers.
• Use a Core Domain Chart to focus investment.
• Shape bounded contexts and reduce team coupling.
• Ship early, learn fast, iterate deliberately.
• End every refinement by asking: “Which problem does this solve?”

• 

  

  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.

  Watch now

• 

  

  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.

  Watch now

• 

  

  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.

  Watch now