Alberto Brandolini on Managing Software Model

There's a confession buried near the start of Alberto Brandolini's talk at GOTO Copenhagen 2025 that anyone who has worked on a codebase for more than two years will recognize instantly. The EventStorming creator—whose sticky-note-covered workshop methodology has become something of a rite of passage in DDD circles—admits he was first exposed to the idea of multiple models nineteen years ago at this very conference, read Eric Evans on the subject, and promptly decided it didn't apply to him.

"I said, yeah, I don't need multiple models. I'm too young for this. My applications are not that sophisticated. And I was wrong."

That kind of candor earns you the room's attention. What Brandolini does with it over the next forty-eight minutes is walk through something more useful than a victory lap: a structured reckoning with why software systems keep ending up in the same tangle, regardless of how good the intentions were at the start.

The pattern everyone recognizes but nobody stops

Brandolini's diagnosis of the "good old times" is essentially a description of entropy dressed in business logic. The model starts small, purposeful, comprehensible. Then a new feature lands. Then another table. Then a stakeholder from a different department needs the same data for a different reason, and suddenly a thing that was built for one purpose is serving four. The coupling deepens. The team grows. The refactoring conversations start happening in what Brandolini memorably calls "the black market"—not in planning meetings or on Zoom, but in Slack DMs and corridor negotiations that never make it into any roadmap.

"From the top you see one thing—yes, this is my roadmap, I promise my delivery date—and behind the scenes there's a lot of black market things going on."

The wake-up call, he observes, only comes when the divergence between cost and return shows up on a financial chart. By then, you're deep in what he calls "the good old times problem": the model has become too large and too hyperconnected to touch safely, but there's always one more feature to ship before the serious refactoring begins. The business doesn't see the pain because the pain is invisible. The engineers see it constantly.

What's interesting about Brandolini's framing is that he doesn't blame individuals or even teams. He points at structural incentives—the investor-driven reward for headcount growth, the delay between architectural decisions and their visible consequences, the fundamental cognitive bias toward adding rather than decomposing. These aren't failures of discipline so much as features of how software organizations operate under pressure.

The bounded context experiment, honest version

The antidote Brandolini proposes isn't new—bounded contexts have been in the DDD playbook for two decades—but his account of actually living with them in production for ten years inside his own company (Avanscoperta) is worth paying attention to precisely because he doesn't sand off the rough edges.

The upside: flat cost of evolution over a decade. Genuinely. The question "what happens if we do this?" never became unanswerable. For a team running ten to twelve bounded contexts on a monolithic architecture with CQRS and event sourcing baked in from day one, that's a real result.

The downside: the discipline is genuinely hard, and it's especially fragile to new team members. The rules that feel obvious to people who designed the system are invisible to someone joining fresh. "There's a tacit agreement between old friends," Brandolini explains. "A new person joins—oh, why didn't you do this? Oh no, stop. We need to talk."

He also flags something more subtle: the human brain is badly calibrated for small bounded contexts. Our natural "brain-sized model" is much bigger than a well-scoped context. The temptation to just connect this and that and run a join query rather than think carefully about which model actually owns a concept is constant. The boundary isn't protecting itself; you have to protect it.

His two main hacks for this are worth noting. The first is a simple rule: don't change a working design unless the purpose of that model has changed. A new feature request isn't a reason to open a sealed context. It's a question: which existing context does this belong in, or does it need a new one? The second is mandatory visualization for any architectural discussion. No invisible arguments. Map what you have, map the problem, map at least three alternatives before deciding. Capture the decision in an Architecture Decision Record. Without that structure, he argues, you're not having an architectural discussion—you're just arguing.

Splitting too late, the multi-country trap, and the "uber domain expert"

Brandolini moves through several organizational scenarios, each with its own particular failure mode. The startup scaling from one team to eight or nine people and suddenly needing to split work across teams is a common one. The problem: by the time the team is large enough to feel the coordination pain, the lack of a map makes the split itself expensive. You end up running large workshops to figure out where the fences should go—which is exactly what you'd want to avoid.

"Maps are cheap when you don't need them," he observes. "If you need splitting too late, then deciding where to split becomes an incredibly complex problem."

The multi-country expansion scenario is where things get genuinely complicated. The intuitive assumption—that entering a second market is easier because you've already built the product—turns out to be exactly backwards in terms of what's being asked of the team. Country one had greenfield implementation, experienced founders, deep domain expertise, and market positioning that attracted talent. Country two gets a brownfield implementation, a more junior local team, domain experts who may not translate one-to-one, and regulations that might be meaningfully different.

The domain expertise problem runs deeper than it looks. Brandolini's taxonomy of warning signs about domain experts who shouldn't be trusted as modeling oracles is sharp: the developer who became a domain expert is risky; the developer who was a developer on the previous version of the software is essentially guaranteed to transmit architectural debt as domain knowledge. And regulators, while authoritative, score poorly as domain modelers—your model needs to operate within the constraints they set, not mirror their specification verbatim.

For cross-country expansion, he argues for what he calls the "uber domain expert"—someone with comparative expertise who can map both similarities and meaningful differences across markets. When you can't hire one, his prescription is to build the expertise yourself: model one country, model the second separately, compare the two, and extract the abstraction layer from actual observed differences rather than assumed ones. His own Italy-Spain workshop for a large corporation failed when run as a single combined session; split into two separate explorations, the outcome revealed that the underlying flow was 99% identical while the organizational structure differed significantly. That's exactly the kind of signal that a combined session would have smoothed over.

What the certainty trap actually costs

The through-line across all these scenarios is a consistent enemy: the expectation of certainty before making decisions. Brandolini is direct about this. Teams that freeze because they "have no idea about the future" usually aren't being honest—they don't have precise requirements, which is different. They have signals. They can reason about plausible futures. They can, as he somewhat entertainingly suggests, use LLMs to get rough orientation on foreign market regulations—not as a trusted source, but as a way to get unstuck from a false binary of "we know everything" versus "we know nothing."

The paralysis he describes in some organizations goes further than uncertainty-avoidance—it becomes fear. Not fear of making the wrong architectural choice in some abstract sense, but genuine fear of touching specific areas of the codebase. When that's the operational reality, the question of where to start decomposing isn't primarily an architectural question anymore. It's a psychological one. His response: map the fear explicitly. The scariest areas to touch are probably the ones where the refactoring is most urgent.

"Most of the decisions are yours. Your territory, your scenario, you know exactly what might be the right thing. But decisions are your blocker."

There's no recipe book for this, he says at the close—and means it. The specific combination of business context, team structure, existing codebase, and market dynamics is always particular. The practices he describes (visual grounding, purpose-driven splitting, early maps, disciplined boundary protection, comparative cross-country modeling) are genuinely useful. But the question of when, where, and how aggressively to apply them remains a judgment call that depends on reading your specific situation accurately.

Which is, when you think about it, exactly what domain modeling has always been about.

— Dev Kapoor, Open Source & Developer Communities Correspondent, Buzzrag