Finding Service Boundaries: The One Rule That Matters
We use lots of heuristics to design (micro)services, but there is only one rule that really matters: maximising our ability to frequently deliver value to customers.
For the past ten years, Domain-Driven Design, and more recently the microservices movement, have championed the need for autonomy — which facilitates customer responsiveness — by finding natural boundaries in the problem domain then aligning technical boundaries with them.
Domain terminology and domain processes are two of the traditional heuristics used for finding autonomy boundaries. However, in my experiences of many different domains, these intrinsic heuristics are not sufficient.
You should not design services solely on inherent attributes of the problem domain.
At the heart of your service design process, you need to factor in the system of work — understand how work items flow through the organisation, and how organisational and technical boundaries can be designed to optimise that flow.
I will be presenting more about designing services at Domain-Driven Design Europe on February 2nd. If you want to discuss any of these topics in person or share your own stories, you can attend my talk “Aligning Organisational & Technical Boundaries for Team Autonomy” or catch me in the hallways afterwards.
Keep applying the traditional heuristics
Since I first discovered DDD many years ago, and still to this day, Eric Evans’ golden rule of focusing on language has been an enlightening way to approach many aspects of software development. Of most relevance, it has enabled me to design highly autonomous teams and services.
To recap this design approach using my previous post , a government agency are providing the ability for businesses to: review information held about them used to calculate taxes, resubmit updated information (e.g. we have 4 car parking spaces not 16), and renegotiate the amount of tax they pay (e.g. I want to pay tax for 4 car parking spaces not 16 please).
After initially analysing the domain, there were 4 contexts that emerged in the technical solution: Review, Resubmit, Renegotiate, and Case Management.
According to the applicability of language heuristic, this model seems reasonable: each context contains specific terminology that is not used elsewhere; minimal sharing of languages between contexts. In addition, all contexts could be argued as business capabilities.
Despite this design satisfying many of the traditional heuristics, however, there is no guarantee it will be effective. You can’t tell how frequently and efficiently teams will deliver value to customers.
In all my experiences, it does not matter how clean your model is or how crisply language fits within your boundaries, you just cannot verify how good your service design is based on intrinsic properties of the domain alone.
But I do still fully recommend you continue to base your design around these traditional heuristics, as part of a larger feedback loop…
Supplement your design skills with Theory of Constraints
You cannot tell if service boundaries are useful based purely on domain modelling and speaking to domain experts alone because the system of work need also be factored in to your design.
In the last post, it wasn’t until work items were flowing through the organisation that bottlenecks appeared and thus the consequence of the service boundaries were accentuated. The Review and Case Management contexts became bottlenecks — those teams had so much work they were blocking other teams (leading to intense politics and drama).
Rather than typically being an organisational or management issue to fix, the problem was resolved by using the feedback of bottlenecks to reexamine the problem domain, reapply the traditional heuristics, and redesign the organisational and technical boundaries to remove the bottleneck.
Even though the end result showed the need for composite applications rather than a case management context, until the original design had become part of the system of work, there were not enough clues to suggest a separate case management system was poor design.
Optimal designs, therefore, are highly contingent on circumstance (domain, business, organisational factors). For another domain in another organisation with a similar business process, starting with the three contexts may have been the wrong choice and a case management system may have emerged as the optimal solution.
In all my experiences, it really is this tricky and challenging. There are no hard and fast rules for finding service boundaries.
Language is a great heuristic. Business capabilities and organisational departments can sometimes lead in the right direction. But until work flows through the system, you just never know how effective your service boundaries really are until you quantify customer responsiveness.
Customer responsiveness is your service design success metric
Think about your success metric; you want to deliver value as frequently and efficiently as possible to accelerate product development and to make your customers happy.
Unfortunately, you cannot just run your bounded contexts through an algorithm to determine how fast they will enable you to deliver value to customers — they are just one factor in a large, complex system. But Theory of Constraints can help you create a feedback loop.
Even customer responsiveness isn’t the true goal — positive business and customer outcomes are. Much of the time, optimising for delivery to customers as frequently as possible leads to better business outcomes. But not always. In a future post I will discuss another design heuristic to help you know when to violate this rule.
Through the lens of Theory of Constraints, you look for the biggest constraint in your organisation; which team has the biggest backlog of required work or WIP, preventing value from being delivered to customers — where is the biggest bottleneck?
So continually look for clues that indicate bottlenecks: teams frequently blocked waiting for others, multiple teams frequently locked in meetings on most work items, etc.
When you feel those types of organisational pains, reexamine the boundaries of your services using the traditional heuristics (language, business capabilities…). Perhaps your boundaries need better alignment with the system of work to remove bottlenecks. Sometimes at the expense of perceived domain purity.
Don’t worry — the goal is to consistently deliver value, not to create beautiful models. You’re not violating any sacred DDD rules.
Accordingly, an important quality to aim for is team autonomy. If teams can frequently deliver value without interruption or blockage, you are unlikely to have many significant bottlenecks.
In this post you have seen how some of the biggest constraints to an organisation’s productivity and innovation are best solved by software developers. My talk at DDD Europe will contain more advice and techniques showing how developers can lead key transformations in organisations by aligning organisational and technical boundaries.