Growing & Thriving in a Multi-model World • Alberto Brandolini • GOTO 2025
Alberto Brandolini delivers a compelling talk on how to combat software model decay and avoid the "Big Ball of Mud" by strategically applying Domain-Driven Design principles, especially Bounded Contexts. He emphasizes the critical role of visual thinking, structured architectural discussions, and organizational habits in maintaining clean, evolvable systems, particularly when scaling across teams and international markets. The talk highlights the need for continuous design effort, disciplined decision-making, and proactive identification of model boundaries to build resilient software in complex socio-technical landscapes.
Alberto Brandolini’s presentation at GOTO Copenhagen 2025 delves into the complexities of managing software models over time, emphasizing how to avoid the “Big Ball of Mud” phenomenon through strategic model decomposition. He highlights the socio-technical stack’s influence, encompassing architecture, domain, organization, teams, and human psychology, and discusses how different strategies fit various stages of software evolution.
The Pain of “Good Old Times”
Brandolini begins by illustrating the common pitfalls of a single, monolithic model. Initially, developers might believe multiple models aren’t necessary, but unchecked growth leads to hyperconnected, unmanageable systems. This often results in a “Big Ball of Mud” where adding new features becomes increasingly difficult and refactoring is perpetually postponed due to business pressure. He critiques the “delusion of parallelism,” where adding more teams paradoxically increases dependencies and coordination costs, particularly for teams at the heart of the system that desperately need refactoring. The financial impact, where money grows but returns plateau, eventually forces a recognition of the problem.
Common solutions like microservices or splitting around data often fail, merely transforming dependencies into distributed ones. The core issue with a single model is its attempt to serve multiple purposes, leading to more stakeholders, trade-offs, risks, and fear of change. Brandolini notes that no one intentionally builds a big ball of mud; it’s a consequence of delayed feedback and, often, investor pressure for speed over sustainable design.
Starting with the Right Foot: The Bounded Context Approach
Brandolini then contrasts this with an alternative approach, exemplified by a 10-year-old in-house project. This project embraced Domain-Driven Design (DDD) principles from its inception, utilizing CQRS, Event Sourcing, and 10-12 distinct bounded contexts. He defines a Bounded Context as a model with a single purpose, a sharpened language, well-defined boundaries, private persistence, and implementation autonomy, communicating with others via commands, events, and read models. The concept of Ubiquitous Language in this context isn’t about universal terminology but recognizing that different contexts require different languages.
This disciplined approach yielded significant benefits: a flat cost of evolution and consistent feature addition for a decade, demonstrating that a well-designed system can maintain its integrity over time. However, this discipline comes at a cost, requiring significant modeling effort and being vulnerable to the introduction of new team members who may not share the existing tacit agreements.
The Challenge of Discipline and Visual Thinking
Brandolini explains that maintaining discipline is hard because the natural human tendency is to think in large, unbounded models. Brain laziness often leads to combining functionalities across contexts (e.g., a single invoice concept serving both forecasting and billing), ignoring the signals of distinct purposes. Delayed feedback further exacerbates this, as the benefits of model separation are not immediately apparent.
A crucial insight was the difference between verbal and visual thinking. Verbal discussions often rationalize complex, intertwined concepts, making them seem coherent (e.g., “of course forecast needs invoices”). However, when visualized on a map, the logical inconsistencies and hidden dependencies become evident. Brandolini advocates for Context Maps as essential tools for grounding modeling discussions and preventing the creation of canonical, multi-purpose models.
He draws parallels to habit formation, suggesting “hacks” to instill good design practices:
- Don’t change working design: A functional, purpose-built component should not be reopened for new features. Instead, new features should find their “right bucket” (i.e., a suitable existing bounded context or a new one).
- Structured Discussions: Implement a repeatable architectural discussion recipe: visualize the problem, highlight critical issues, explore multiple alternative solutions (at least three), assess pros/cons, and document decisions with Architectural Decision Records (ADRs). This emphasizes the importance of visual tools (like Miro) and balancing solo thinking with collaborative team time.
This disciplined approach, including the explicit rejection of terms that don’t fit a context’s purpose, fosters a system where doing the right thing becomes easier. The outcome is a simpler model that opens up new business opportunities. While the implementation may remain a logical monolith, the clarity of logical boundaries protects against decay.
Strategic Splitting and Organizational Challenges
When to Split?
Brandolini discusses the common scenario in growing startups where business pressure often postpones crucial design decisions. As teams grow (e.g., 8-9 people), the need for splitting emerges, but often without prior mapping or clear boundaries. He stresses that the right time to split is “when the signals are clear and the decisions are cheap,” not when paralysis due to coordination costs has already set in. He clarifies that logical separation does not necessarily mean physical separation (i.e., microservices), though high turnover might warrant stronger physical boundaries.
Detecting Where to Start
Faced with a “holy mess,” organizations often seek perfect starting points for refactoring, leading to paralysis. Brandolini advises: “You just take something from the floor and put it in a drawer.” Instead of perfection, focus on taking any meaningful step. Big Picture Event Storming can help visualize the entire system, identify friction points, and prioritize refactoring efforts where the business value is highest or where the “fear of change” is most pronounced. This pragmatic approach acknowledges that architectural decisions must balance technical purity with business payoff and human psychological factors.
Multi-Country Expansion and Uber Domain Expertise
The Colonization Trap
Expanding a successful product from one country to others presents unique challenges. Many companies mistakenly assume that market differentiation is primarily about language, overlooking deeper cultural and regulatory nuances. The “colonization” approach—where an existing solution is adapted for a new market—often leads to junior teams working on brownfield implementations, a task significantly harder than greenfield development. This can result in costly cycles of hiring new experts and struggling with misaligned market positions. Brandolini stresses that software engineers must engage with business signals but not blindly follow business directives that lead to unsustainable codebases.
The Need for Uber Domain Experts
For multi-country contexts, reliance on standard domain experts is insufficient. What’s needed is an “uber domain expert” who possesses cross-country expertise, capable of describing commonalities, differences, and transcended patterns across markets. Such experts are often hard to hire, especially for startups. Brandolini suggests that teams might need to become these experts by systematically modeling behavior in different countries, comparing these models, and abstracting common patterns.
Final Takeaways: Embracing Uncertainty and Action
Brandolini concludes with several key lessons:
- No Universal Recipe: There is no single book or guide with all the answers; decisions are context-dependent and ultimately yours.
- Decisions are Blockers: Reduce the number of people involved in decisions to accelerate the process.
- Map Early, Map Cheap: Early mapping pays off significantly, as maps are cheapest when you don’t desperately need them. Signals for splitting emerge from purposes, subdomains, areas, or departments.
- Play on Habits: Identify recurring mistakes and intervene at those moments with new practices to change decision-making.
- Confront Fear: Many problems stem from fear, not lack of ability. Create safe spaces for exploration (e.g., prototypes) to overcome this.
- Stop Expecting Certainty: Embrace the gray zone. You won’t have full certainty when making critical decisions; explicit exploration and willingness to decide with some ambiguity are essential.
- Become Your Own Expert: Especially in niche or evolving domains like cross-country expertise, don’t wait for a messiah; actively build the knowledge yourself.
The talk underscores that effective software design and evolution in complex systems require a holistic approach that integrates technical rigor, organizational dynamics, and an understanding of human behavior.