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

Satisfying Software – Kenny Baas-Schwegler

Domains and subdomains: the supermarket metaphor

Gien: How do you explain the difference between a domain and a subdomain to people?

Kenny: My way of explaining it started from a running joke in the DDD community about tomatoes — a tomato is a fruit biologically, but in a supermarket it's a vegetable, and in a theatre it's feedback. I thought that was an interesting metaphor to expand on. A domain is like an aisle in a supermarket, or the whole supermarket itself depending on the size. The aisle might be labelled "Asian food," and within it you have sections — Japanese, Indonesian, Indian. Those sections are the subdomains. A short definition of a domain or subdomain is: where knowledge is categorised, where problems requiring specific knowledge live.

Gien: I usually say it's a sphere of knowledge or an area of activity. It's deliberately fuzzy because the concept itself is fuzzy — it's genuinely hard to say where a domain starts and ends. The tomato thing illustrates that well too: if you just focus on the word "tomato," you'll find it in three different places in the store. That's why you need to look at the sphere of knowledge rather than the label.

Kenny: Exactly. Focusing on the word alone isn't useful. You want to ask: what are the problems, what knowledge is needed here?

From subdomains to bounded contexts

Gien: How do you get from the grocery aisle to a bounded context?

Kenny: That's where the metaphor gets a bit muddy. You can think of the products on the aisle as bounded contexts — they're solutions to the problems the subdomain represents. A bounded context is a solution for a specific problem. The subdomain categorises the problems and spheres of knowledge; the bounded context is how you solve one of those problems in software. But the metaphor breaks down there, because a grocery shop isn't really a complex domain in the DDD sense. Still, even in a simple shop you get interesting questions — baking soda appears in both the cleaning aisle and the baking aisle, because it solves a problem in both. That kind of ambiguity is exactly what you deal with in software design too.

Gien: For me a bounded context is a tool to manage complexity — an explicit boundary you deliberately draw, within which you solve a specific problem. That's where the metaphor stops being enough.

Kenny: Right. That's the real essence of why bounded contexts exist, and the supermarket can't fully take you there.

Subdomains and bounded contexts don't have to align

Gien: One thing I keep seeing is companies wanting their subdomains and bounded contexts to be neatly nested — a subdomain contains its bounded contexts in a tidy hierarchy. But there isn't a one-to-one relationship between them, is there?

Kenny: No — it can be one, two, or three. It's a different kind of boundary. Saying subdomains and bounded contexts must align is like saying country borders and language borders must align. In the Netherlands, we speak Dutch, but near the German border people speak German, and in Belgium German is actually an official language. Country and language boundaries don't match, and trying to force them to would be absurd.

Gien: As a designer I never focused much on subdomains for exactly that reason — I couldn't control them. My tool was the bounded context and I started there. But a lot of companies are fascinated by getting the subdomains right. Where does that come from?

Kenny: I think people hear "domain-driven design" and assume the first step is defining the domains. And there's something to that, but the domains in the organisational sense don't necessarily align with the domains in the DDD sense. The org chart exists to manage people and budgets, not to manage software solutions. The DDD domains are more like design inputs: you model them, then ask how you'd reorganise your teams and bounded contexts to better align — knowing full well you'll never get a perfect match, and that's fine.

Gien: In enterprises, the domain conversation is often political. Teams get budgets because of their domain. It's less about knowledge categorisation and more about organisational ownership.

Kenny: Yes. And the moment the market shifts — say a bank decides to stop distinguishing private and business banking and become a digital bank instead — your entire domain alignment breaks overnight. It's always a temporary design. What matters is keeping it as a direction to move towards, not treating it as a fixed structure.

Designing bounded contexts: focus on interaction, not just structure

Kenny: Barry O'Reilly talks about how we're too focused on objects and structure — that goes all the way back to Plato. Object-oriented design was originally about how objects interact with each other, not about what the objects are. The same is true for Team Topologies: people focus on the team shapes, when the real value is in modelling the interactions between teams. And it's the same with bounded context design — focus on how bounded contexts interact with each other through strategic patterns, rather than on the bounded contexts themselves. The structure comes from that interaction.

Gien: I do focus on the bounded contexts themselves, but while designing them I'm always looking at interaction too. What you want is something like Goldilocks bounded contexts — big enough that a team can hold a coherent domain model and language without ambiguity creeping back in, but not so small that your complexity just moves into the integration layer.

Kenny: Exactly. And I'd add: postpone structuring too much, not just naming. If you converge on structure too early, you stop being able to fill in gaps with new creative ideas. Chaos breeds creativity. Once everything has a name and a box, you stop diverging.

A real example: DHL and the address problem

Kenny: At DHL, there's an interesting case around address validation. Getting deliveries to the right address is genuinely hard — Belgium alone has streets with names in Dutch, French, and German. What used to happen is that a parcel would be collected, attempted for delivery, found to be non-deliverable, and routed to a back-office room where someone fixed the address manually. Very late in the value stream.

We asked: what if we moved address validation to the front of the process instead? Two bounded contexts from two different operational domains — one at the front, one at the back — were redesigned as a single team's responsibility. The team that catches the problem at the front is now the same team that used to deal with the fallout at the back, so they have every incentive to optimise. That redesign could only happen by looking at the value stream and asking which bounded contexts should move, regardless of which organisational domain they originally sat in.

Gien: That's a good example of why software design has to be decoupled from the org chart. In a biotech company I worked in, liquid transfers — picking up a small amount of liquid and moving it — appeared in nearly every part of the domain. If you modelled one-to-one with the business domains, you'd have that logic duplicated in every service. Instead you create one bounded context for liquid transfers, with its own domain model and language, and let it serve across all the domains that need it.

Naming bounded contexts: start with the problem, not the solution

Gien: When naming bounded contexts, I try to use a verb rather than a noun. If you name it after a thing — "Invoice" — people zoom in on the aggregate and start thinking the bounded context is just a wrapper for that entity. If you name it after what it does — "Invoicing" — you get a much better conversation about what belongs inside it.

Kenny: My heuristic goes a step further: name it after the problem it solves in the problem space, and make the name ridiculously long at first. Take a cinema booking system — people often call it "seat reservation." But that's a solution, not a problem. What's the actual problem? People want to choose seats for a screening. But also: the cinema wants to fill up — you can't leave an empty seat between two bookings. So the problem is richer than "seat reservation." Someone once named a bounded context "filling up the cinema surface," which I loved. It immediately frames things differently. If you're only thinking about someone picking a seat, you build a seat-picker. If you're thinking about filling a cinema, you start asking very different questions.

Gien: So "invoicing" becomes something like "creating records of money owed."

Kenny: Exactly. Start with that mouthful. People will eventually shorten it, and that's fine — but starting long keeps you in the problem space. Starting short jumps you straight to a solution that might not be right.

Don't name things too soon — or at all, if you have to

Gien: Teams often want to settle on names after the very first design session, and treat that draft as the final answer. But a first draft is never the best design. You need to iterate — look at the relationships, check how many teams you'd need, try to build a domain model inside the boundary and see if it even makes sense. Sometimes it doesn't, and that's useful information.

Kenny: If people name things too soon I start deliberately using different words to cause a little confusion. Domain experts will tell you quickly if a word is right or wrong. It causes some discomfort, but that discomfort is productive — structure that arrives too early closes off creative possibilities.

Gien: I had a case where a company was completely stuck on the word "campaign." It appeared everywhere, meant different things to different teams, and every attempt to define it became a political dispute. In the end I started using placeholder names — a dinosaur and a crocodile — just to break the attachment and defuse some of the tension. Once you detach from the label, you can actually design.

Kenny: If you genuinely can't agree on a name, call it something people will want to change. I once used "the B&B Full of Love bounded context," after a Dutch TV show. Half the group had never heard of it, half watched it every day. I was certain it would get renamed quickly. That's the point. And if you really don't know what the problem is yet, just call it a placeholder — but make sure it changes eventually.

The rant: jumping to solutions before understanding the problem

Gien: What still frustrates you about domains, subdomains, and bounded contexts in practice?

Kenny: Two things. The first is the ongoing debate in the DDD community about problem space versus solution space. The distinction matters enormously because it's so easy to fall into the trap of designing solutions before you've understood the problem. When I walk into a company and they say they want to do more DDD, I ask: when did you last speak to a domain expert? And it goes quiet.

I was in a session recently where a team knew there was a problem causing errors — had known for months — but they didn't want to analyse it, didn't want to visualise it, and jumped straight to solutions without understanding how the problem actually propagated. The visualisation, done together, is where the understanding comes from. Skipping it almost always leads somewhere worse.

The second frustration is what happens without a feedback loop between engineering and the business. When you find a class in a codebase called something like RefactorPatternManagerClass, what you're looking at is an engineer who needed to add a concept that didn't have a name yet in the domain language — and nobody looped back to the domain experts to resolve that. Rebecca Wirfs-Brock and Matthias Verraes wrote well about this: sometimes you do need to add new concepts, but doing domain-driven design without that feedback loop makes things worse over time, not better. The business also needs to evolve its language. That's hard, it's social, and it's more or less what we wrote the book about.

What does satisfying software mean to you?

Kenny: I'm not thinking about the software when I answer this — I'm thinking about a team. One of the last teams I worked with had 14 people maintaining one large ball of mud. Over eighteen months we decomposed it into 14 bounded contexts. They wrote a case study about it in Nick Tune's book.

What was satisfying was walking into a room, looking at a metrics board — business metrics the engineers themselves had created — and watching them notice a drop, trace it to the code, and fix it in five minutes. Users never knew. The customer never knew. The team was entirely in charge of the problem because they understood the domain well enough to know exactly where to look. Someone had made a typo. Fixed, deployed, done.

In the whole conversation that led to that fix, nobody used a single technical term. They talked about the business problem. And the product owner in that team wasn't managing a backlog — he was bringing in opportunities, and the engineers were pushing back with data: according to what we know about user behaviour, this isn't the best solution — but what if we did this instead? That conversation was genuinely equal. No Scrum, no ceremony. Just people who understood the problem, working directly on it.

That's how I got into this industry 14 years ago. My first month I had a two-day course in the business domain, and users were sitting next to me telling me when my code was solving the wrong problem. That felt like the norm. Software that solves a real business problem, that you can see working, and that keeps you inside that full feedback loop — that's what satisfying software looks like.