In software, there are many reasons for breaking up systems and making them more modular, Nick Tune noted in his keynote at the recent DDD Europe 2020 conference in Amsterdam. We lower the cognitive load when we can look at a part of a large system. Teams can work autonomously and independently on different parts. From a business perspective, we can do more granular investments and spend more of our resources on more important parts. In his presentation, Tune discussed modularity and how by dissecting and analysing bounded contexts we can find more modelling options when designing and evolving them.
Tune, a technical leader and consultant based in London, started by noting that when we talk about boundaries and breaking things up in modules, we overemphasize the boundary a lot. The concept of a boundary implies a hard split, but for him it doesn’t work that way. It’s the language that is at the core of Domain-Driven Design (DDD) and bounded contexts, and understanding the language better is key to improving the understanding of boundaries. We have to understand the influence that is coming from outside the boundary to inside the boundary, and usually it’s the language that carries that influence. Bounded contexts are linguistic barriers, but we often overemphasize the boundary and underemphasize the linguistic bit. There is much more influence from outside of the boundary than we understand and expect, because words can have a very different meaning in different boundaries. He therefore claims that we have to understand the domain model of language and bring that into DDD.
In DDD we have the concepts of core, supporting, and generic subdomains, but Tune thinks they are bit vague and hard to quantify. To be a core domain, there has to be a high level of business differentiators inside, but there also has to be some complexity. If we have something very complex with a very high business differentiator, then it’s a decisive core. Having an advantage here means you can dominate the market, and because of the complexity it’s harder for competitors to catch up. Tune has sometimes heard that the core domain may change for a business over time, but for him it will change; evolution is a given.
Another example is a core domain with high a business differentiator but with a very simple solution. This is a warning signal, because how can it have a high differentiation when it’s so simple for a competitor to catch up? Tune calls this "first to market core"; you did it first, but the competitors will catch up because it’s so easy, which means it’s not a defensible position.
Tune defines a "black swan" core as something we didn’t expect to happen or shouldn’t have happened. This is a bit of a conflict with the DDD community who say that we should outsource all generic things. Tune notes that this is often true, but mentions that what is generic can become your core domain even if it doesn’t happen very often. Innovations can happen anytime, changing a generic domain to a core domain, and Tune therefore claims:
There are no generic domains
Another aspect of bounded contexts deals with the organisation of teams. Tune thinks this has some interesting dynamics and he is pretty sure we haven’t yet found out how to organize teams properly. There are data and research that indicates that there is a correlation between continuous delivery performance and a loosely coupled software architecture with an organisational structure to match.
To explain this correlation, Tune looks at how consumers and teams interact. As a consumer, we look for products with a great customer experience. The goal of the teams is to understand what the consumer wants and develop a software architecture that enables this customer experience. This is a loop, and to go faster we need both the architecture and the teams to be in the right shape. We know from Conway’s law that there is a relationship between the organisation and the architecture, but we also know that business is evolving over time and both the architecture and the teams have to evolve as well. There are many patterns of how teams can collaborate, and Tune emphasize that the collaboration can change over time depending on how the different domains and the architecture evolve. The Domain-Driven Design book by Eric Evans contains a number of patterns in the strategic design part that can be relevant.
Tune concludes with some predictions. Since software is representing a domain, it should describe how the domain works, and the domain language we use should be very clear in the code. We are not there yet, but he thinks that Cyrille Martraire’s book Living Documentation shows the approach we should take to document the domain in the code. The evolution of a developer is not a prediction, because it’s already ongoing. He notes that most developers are doing more business-focused work today than when they started. Infrastructure tasks in the cloud are more and more automated, which let developers focus more on the domain; he believes this will continue with developers becoming more of domain experts in the future.
The slides from Tune’s presentation are available for download. He is also the co-author of the book Patterns, Principles, and Practices of Domain-Driven Design published 2015.
InfoQ did a Q & A with Martraire about his book when it was published last year.
Most presentations at the conference were recorded and will be published during the coming months.
