Design for the Problem, Not the Solution with Kenny Baas-Schwegler

Key topics discussed during the conversation

1. Domains vs Subdomains

Kenny uses a supermarket metaphor to explain the distinction. A domain is like the entire supermarket (or a single aisle, depending on scale), while subdomains are the sections within that aisle — Japanese, Indonesian, and Indian food within an Asian food aisle, for example. A domain is simply where knowledge is categorised: a sphere of problems that require shared expertise.

He also uses the tomato example from the DDD community: a tomato appears in multiple places throughout the supermarket (fresh produce, canned goods, etc.), which illustrates why focusing on a single word or concept in isolation isn't useful — context determines meaning.

2. Bounded Contexts

The supermarket metaphor starts to break down here. Kenny describes a bounded context as a solution to a specific problem, like a product on the shelf that solves the problem of cooking Italian food. The subdomain categorises the problem space; the bounded context is the solution space.

Gien adds that a bounded context is a tool to manage complexity: an explicit boundary you design in which you solve a specific problem. Kenny notes that subdomains and bounded contexts don't need to have a one-to-one relationship — just as country borders don't align with language boundaries.

3. The Organisational Dimension

A recurring theme is the tension between organisational structure and software design. Domains in the DDD sense are design tools — not org chart boxes. In large enterprises, what people call "domains" often reflects budgets and reporting lines, not knowledge boundaries.

Kenny shares a practical example from DHL: address validation was happening too late in the parcel processing workflow, causing costly failures. By moving the relevant bounded contexts earlier in the value stream and aligning two teams around the combined problem, they were able to optimise end-to-end. Sometimes the right move is to shift a bounded context across domain or team boundaries — even if the naming doesn't follow.

4. Focus on Interaction, Not Structure

Both Kenny and Gien argue that the field over-focuses on structure — defining bounded contexts and subdomains — at the expense of understanding interactions between them. Kenny draws a parallel to object-oriented design (where the original intent was about how objects interact, not the objects themselves) and Team Topologies (where the real insight is about team interaction modes, not team types).

Gien describes the goal as "Goldilocks bounded contexts" — big enough to model a coherent domain and language, small enough that complexity doesn't collapse into the interactions between contexts.

5. Naming Bounded Contexts

Both hosts agree: name towards the problem, not the solution. Gien recommends using verbs rather than nouns — "invoicing" rather than "invoice" — to keep teams focused on the sub-process rather than drifting into aggregate-level thinking.

Kenny's heuristic is to start with a deliberately long, problem-focused name. His cinema example: instead of "seat reservation," start with "filling up the cinema for a movie screening." The verbosity forces a richer problem conversation, and the name can be shortened later once the real problem is understood.

Key tactics mentioned:

• Postpone naming until the problem is well understood

• If a team settles on a name too early, introduce competing names to provoke rethinking

• Use placeholder names (even absurd ones like "B&B Full of Love") to discourage premature attachment

• Chaos breeds creativity — structure too soon and you close off better solutions

6. Common Frustrations (Rant Away)

Kenny's main frustrations with how DDD is practised:

• Teams jump to solutions before understanding problems in detail — they know something causes errors but haven't mapped how or why

• People claim to do DDD but haven't spoken to a domain expert recently

• Engineers create concept names that have no meaning to the business (e.g. "refactor pattern manager class"), breaking the feedback loop that DDD depends on

• The business also needs to adapt its language — DDD is a two-way process, and that's socially hard

7. What Satisfying Software Looks Like

Kenny describes a team of 14 that migrated a big ball of mud into 14 bounded contexts over 18 months. The defining moment: the team spotted a drop in a business metric on their dashboard, traced it to a typo in the code, fixed it in production within minutes — all without users noticing and without a single technical conversation. They spoke entirely in business terms.

The product owner brought opportunities; the engineers brought data and domain knowledge. No scrum ceremony. No backlog management. Just a shared understanding of the problem and the autonomy to act on it. For Kenny, that's the full picture of satisfying software.