Accidental Complexity in the Heart of Software

Dieser Blogpost ist auch auf Deutsch verfügbar

• DDD takes domain complexity as a given – but offers no tool to question whether that complexity is truly essential or just homegrown.
• In modernization projects, existing processes get modeled with DDD rather than challenged – the new architecture ends up reproducing the old dysfunction with shinier technology.
• Time pressure, no clear mandate, and structural self-interest among stakeholders prevent processes from being simplified.
• Tools like Domain Storytelling to-be exist but are rarely used in practice, because the project context is geared toward delivery, not change.
• Complexity also serves as a status symbol: it signals expertise, creates work – and is therefore rarely actively reduced.
• The most important question isn’t how to model something, but whether it needs to exist at all.

Over the last ten years we have been able to make an interesting observation: there has been a wave of digitalization and modernization projects. Around the same time, Domain-Driven Design went mainstream. Tactical patterns like Aggregate or Repository, as well as strategic patterns like Context Maps or Bounded Contexts, are everywhere today – including, and especially, in those modernization projects.

At first glance this is merely a temporal correlation. But there is good reason to believe that more than coincidence lies behind the simultaneous rise of modernization projects and the growing popularity of DDD. That is what we want to explore in this post.

“All it can do is control it”

The canonical source on Domain-Driven Design is Eric Evans' book of the same name[1]. Martin Fowler writes in the foreword that the complexity at the heart of a software system cannot be avoided – all software can do is control it. Evans himself is no less explicit in the preface: the most significant complexity of many applications lies not in the technology, but in the domain itself, and that complexity must be handled.

Not a single pattern in the blue book focuses on questioning complexity, let alone eliminating it.

Essential or accidental?

In 1986, Fred Brooks distinguished between essential complexity and accidental complexity in No Silver Bullet[2]. Essential complexity lives in the problem itself – it cannot be argued away. Accidental complexity is made: grown historically, shaped by organizational structures, never questioned by anyone.

Evans assumes in the blue book that the domain complexity we encounter is genuinely essential. The domain complexity is taken as given. DDD offers tools to make it manageable. Aggregates, Bounded Contexts, Anti-Corruption Layers, Domain Events – these are all tools for exactly that task. Not a single pattern asks whether this complexity actually needs to exist.

A significant part of what we consider essential complexity is in reality homegrown. Processes that have “always been this way” are no longer perceived as requiring justification. Their mere existence is taken as proof of their necessity. This is not a DDD problem. It is better explained by the psychological phenomenon of status quo bias, well described by Kahneman and Tversky: losses weigh psychologically heavier than equivalent gains, and giving up the status quo feels like a loss.

DDD is the right tool for essential complexity. The problem is that the methodology offers no answer to the question of how to recognize whether complexity is truly essential. And because DDD’s tools are so good at making complexity manageable, the pressure that would be needed to even ask that question subsides. It is like a very effective painkiller: once the symptoms are well treated, nobody asks about the cause anymore.

What happens in practice

From my own observations across a wide range of projects, I can say that the use of tactical DDD patterns has become an unquestioned modus operandi. That is not necessarily wrong – they are a useful shared design language, by now almost a lingua franca. But it is also a symptom of complexity being increasingly accepted as a normal state of affairs.

With the strategic patterns, things get more interesting. Tools like Bounded Contexts, Context Maps, and Subdomains are explicitly designed to find the right cuts. Evans and Vernon would never say: trace the existing departmental boundaries and call that a Context Map. Yet that is exactly what happens far too often. The monolith is decomposed, the Bounded Contexts follow Conway’s Law, and the new architecture mirrors the old organizational structure. The dysfunction gets new clothes.

This is not a misapplication that can be blamed on DDD. But it happens systematically, and the explanation lies not in DDD itself but in the context in which it is deployed.

The result is often that new software is built with modern technologies, yet it merely reproduces the old processes. Frequently not even that – because in the legacy world many processes are not explicitly modeled in software at all, but live in people’s heads and in Excel sheets.

A symptom of such modernization projects is user stories that describe only the desired effects on the user interface, while keeping silent about the underlying business process – a badge that displays a status, a button that saves it, and a business workflow that continues to happen entirely in the heads of employees, outside the expensively modernized software.

Too late, too much pressure

Why is this? There is no simple explanation, but in my experience several factors play a role. One is that modernization projects often do not start when it would make sense, but when the pain becomes unbearable. The legacy system causes so many problems that it needs to be shut down as quickly as possible. That very pressure is why nobody has time to rethink processes anymore.

Reinertsen[3] popularized Cost of Delay as a metric in the context of new product development: what does it cost us for every week we bring the product to market later than planned? But the concept applies equally to legacy modernization. Those who modernize early still have room to make decisions. Those who wait until things are on fire modernize under emergency conditions – every further delay in retiring the old system is extremely costly.

Modeling existing processes with DDD does take time. But it takes less time than genuine process reflection and change, and above all it requires no organizational courage. Under pressure, the methodology that saves both will always win.

The missing mandate

Even without time pressure: clients typically order software, not process consulting. IT architects have a mandate for technology, not for the business domain. Everyone does their job. Nobody does the job that is actually needed.

There is an important reason why the mandate is so rarely given that goes beyond time pressure and role definitions. Process simplification is simply existentially threatening to some stakeholders. Those stakeholders and corresponding departments have a structural interest in the existence of processes that need to be managed. That is not a criticism; it is rational self-interest, shaped by organizational structures and incentives. But it explains why the question of simplification is so rarely asked.

Domain Storytelling to-be – the neglected tool

The tool for the right step does exist, by the way. Hofer and Schwentner built the to-be scenario into Domain Storytelling[4] as an equal mode, not an afterthought. The explicit purpose is not to model how things are, but how they should be.

In practice, it is almost always only as-is, or a half-hearted to-be that does not dare to deviate significantly from existing processes and structures – simply because the project context is oriented toward implementation, not process change. The moment when a to-be that actually changes something would be possible has often already passed by the time the project starts.

Complexity as a status symbol

There is one more dimension that is rarely discussed openly. Some people practice DDD not despite the complexity, but because of it. Complex solutions signal expertise. The DDD vocabulary signals community membership. Whoever eliminates complexity has nothing to show for it. Whoever presents a sophisticated domain model demonstrates skill.

This is a specific manifestation of what Graeber describes in Bullshit Jobs[5]: people who create meaning for themselves by managing complexity they generate themselves. For consultants, a structural incentive adds to this: complexity creates work.

The sobering balance sheet

The wave of digitalization and modernization projects of the last ten years was real. The results of these projects are sobering. The main obstacle is usually not bad technology, but an organization’s lack of readiness to change.

That is no coincidence. It is the direct consequence of treating modernization as a technical problem. New systems, new architecture, carefully modeled domains – but the organization stays as it is. Then the outcome is predictable: the dysfunction outlives the technology.

Conclusion

Modernization and digitalization projects are not technology projects. They require an organization that is ready to change – and that is more than introducing new software and training employees in how to use it. As long as this is not understood, as long as modernization is treated as a technical problem requiring technical solutions, nothing will change structurally. DDD offers the perfect tool for that mindset, and nobody has a strong incentive to change it.

What developers and consultants could do: ask persistently. Why does it have to be this way? Why not just leave the legacy system running? Not as rhetoric, but as a genuine question, asked again and again. The most important question is not how to model something, but whether it needs to exist at all.

1. Eric Evans: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2003  ↩︎

2. Fred Brooks: No Silver Bullet: Essence and Accidents of Software Engineering, 1986  ↩︎

3. Donald Reinertsen: The Principles of Product Development Flow, Cenna Books, 2009  ↩︎

4. Stefan Hofer, Henning Schwentner: Domain Storytelling, Addison-Wesley, 2021  ↩︎

5. David Graeber: Bullshit Jobs, Simon & Schuster, 2018  ↩︎