Managing Complexity in Complex Adaptive Systems with Domain-Driven Design
Modern organisations are infinitely complex systems. Layers of inextricably interlinked dependencies between people, policy, and technology. Their emergent behaviours are often impossible to anticipate.
Earlier in my career, for instance, I witnessed how a small change in software architecture introduced a new cross-team dependency that snowballed into enterprise-scale bureaucratic warfare.
The productivity, innovation , culture - and fundamentally - the success of an organisation, is massively determined by how it manages and responds to the complexity arising from its millions of dependencies.
Domain-Driven Design (DDD) is a bottom-up approach to managing complexity in complex adaptive systems. The essence of DDD is to uncover and model dependencies — to make hidden complexity explicit.
Understanding inherent system interdependence and aligning with it is key to creating sustainable software services and highly autonomous teams. Accordingly, combining DDD with other system perspectives, like Theory of Constraints, is powerful.
In this post, I want to show you how you can benefit from DDD’s complexity modelling techniques without having to invest hours of your time learning lots of new concepts.
Three Pillars of Domain-Driven Design
To fully exploit the potential of DDD’s practices, it’s important to understand three of DDD’s fundamental pillars.These three assumptions at the heart of DDD are three elements essential to optimal software & product development.
- Optimise aligning technical efforts with business & customer value
- Design cohesive modularity (aka autonomy) at multiple levels
- Collaborate across skills and roles
For the past decade, the DDD community has been continuously innovating on ways to get better at these skills.
Optimising for Core Business Needs
There are a plethora of software development anti-patterns involving well-meaning software developers wasting their time on activities that aren’t economically sensible. For example, architectural gold plating.
DDD addresses this problem by making business value a first class modelling construct. Modelling techniques are used to delineate key business differentiators from supporting capabilities and utilities.
Seeking to understand business value at a granular level is a fundamental element of the DDD mindset.
Cohesive Modularity
Cohesive modularity is the pursuit of boundaries that group related concepts — the primary mechanism for managing the positive and negative effects of dependencies.
Poor boundaries in your code mean your organisation is built on foundations that will amplify the negative effects of dependencies. Cohesive code boundaries, on the other hand, facilitate autonomous teams.
They will have few dependencies on other teams giving your organisation the ability to have fine grained control over independent streams of work. Subsequently, you’ll have more granular prioritisation capabilities and improved flow.
Cross-skill Collaboration
DDD also has a uniquely-specific view of improving cross-skill collaboration — a shared language should be used by business, technology and all interested people.
To identify complexity, it is vital to have multiple perspectives of the system. The shared language is essential for those multiple perspectives to be combined into a single model that everyone can contribute to, comprehend, and have conversations about.
Over time, new insights will emerge, business priorities will change, and the system will constantly evolve. The shared language plays a key role in keeping everyone aligned with an evolving system, ensuring hidden complexity becomes explicit.
DDD Techniques for Managing Complexity
You don’t need to be an expert in Domain-Driven Design to apply the modelling techniques and profit from their benefits. Here are a list of activities used by DDD practitioners that you can use right away.
Event Storming
For a whole variety of reasons, Event Storming is the most popular and probably the most effective DDD technique. Event Storming produces spectacular business insights.
It’s power is derived from deceptively simple principles: co-locate a group of people who each have a different perspective of the system, and use post-it notes to model business processes on the wall.
Hidden complexity, risks, unknowns, and business opportunities will all emerge through conversations that the model triggers. A picture will emerge of what is most important for the business, and where everybody’s efforts can be most advantageously applied.
Event Storming is a major contributor to improving competency in all three pillars. The biggest business problems and opportunities will emerge during the workshop. Inherent domain complexity will be visualised allowing cohesive boundaries to be designed. And the shared model encourages everyone to align on a shared language.
I cannot recommend Event Storming highly enough. If you give it a try, I’m sure you won’t regret it. I can help you run workshops, but don’t let any excuse stop you trying for yourself.
Domain Storytelling
A new technique for modelling that has emerged in the past few years is domain storytelling. Domain storytelling is a more granular technique for exploring specific use cases and scenarios.
Domain stories encourage business and domain experts to explain how the domain works as a story; a great way to engage other members of the team and communicate complexity in the domain and value provided to the business.
The stories are created using the shared business language, therefore, acting as an alignment point. The stories can be created, stored, and evolved over time and they support remote collaboration.
Contrastingly, Event Storming is very strict about co-location and less conducive to durable documentation. However, domain stories are the perfect tool for modelling the key areas of your system uncovered during Event Storming.
Four types of notation are used in domain stories — actors communicate via work items as part of activities. Comments can be used to add textual descriptions. Additionally, boundaries can also be shown.
When you need an asynchronous collaboration process, your scope is focused, or you don’t have the unlimited model space needed for Event Storming, you will get a lot of benefit out of exploring your business domain by trying domain storytelling.
The Business Model Canvas
One technique I’ve been using for the past five years to improve the focus of DDD initiatives is the Business Model Canvas.
The canvas lays out the critical aspects of a business model: value propositions, key activities, revenue streams, and more. This information is tremendously valuable in guiding modelling efforts and engineering efforts by allowing the whole team to understand what is valuable to the business.
Another person who has used the Business Model Canvas in combination with DDD is Javier Fernandez. Last year he gave a talk about his naughty DDD experiment involving his company’s CEO. Javier’s story is incredibly entertaining and contains a very important message about collaboration on software projects.
Next Steps
Your organisation is a complex adaptive system and you should constantly be striving to uncover dependencies and mitigate their impact. How you choose to approach this problem is your prerogative, however, DDD is one approach I encourage you to consider.
You can put all of the theory to one side and immediately begin modelling your system with practical DDD techniques like Event Storming. You don’t need a big up front investment to start benefiting, in fact I encourage you not to.
I love facilitating DDD workshops and you can hire me for training, but outside help is not mandatory. The real secret is practice — there is no perfect model, but there is always a better one.
If you’d like to run your own workshops, I recently shared a workshop activities booklet and an exercise booklet from mine and Zsofia Herendi’s Strategic Domain-Driven Design workshop. We are happy for you to use these materials however you wish.
