When you work in a company which transforms into an agile organization, sooner or later people start talking about designing teams and technology according to domain boundaries.
Yet, if you ask your colleagues what a domain is, you’ll find out that obviously there is no common understanding of what a domain is.
This article tries to explain how to deal with domains – with a focus on team organization.
Let’s look at Wikipedia first. You’ll find that the term “domain” can mean many different things in different contexts.
In a product organization, you are probably using Scrum as a framework, and Domain-driven Design (DDD) to identify domains which you map to your teams.
So let’s check DDD’s definition of a domain:
I don’t know if this helps a lot, to be honest. It seems we shall find a department where everyone has the same understanding of terms and processes and everyone more or less works on the same things. If this is our domain, we can build software for the department and dedicate a single team to the development work for this department.
I think this sounds right –somehow–, but it’s still a little bit abstract.
Let’s take a step back.
Lego
Imagine you have a box full of Lego blocks of all colors and sizes and you want to build a car.
Before you begin building, you might want to sort your Lego blocks so that you’ll find what you need quickly while building your car, so that you can focus on the build process instead of searching for matching blocks.
How do you sort your Lego blocks, though?
- You can put all blue Lego blocks together, all red ones in another area, and sort all your Lego blocks by color.
- Instead you could organize your blocks by form and size. Stack all the 4×2 blocks up in piles, put 2×2 together, and so forth.
- You can combine the ordering approaches described above and put all red 4×2 blocks together, next to it the blue 4×2 blocks, etc.
- Or you leave all blocks in the box, spend more time searching during the build process but don’t have to spend your time sorting the blocks beforehand.
By sorting your Lego blocks, you actually create domains, and it seems you can create domains based on several criteria.
Sorting Criteria and Purpose
If you can define your own sorting criteria do identify domains, the question is “how do you find the right criteria for your domain separation?”.
Let’s get back to our Lego example.
- If you don’t care for the color of your car, you can use Lego blocks of any color. Form and size of the blocks will still be relevant, though. In this case sorting your blocks by color would create extra effort during domain creation, but it would not help you while building your car.
Therefore, in this case sorting your blocks by form and size would help you with your build process later on. - If the car you are going to build shall be of a specific color scheme, finding blocks of the right color will be as helpful as finding the right form and size quickly. It would not be useful to only find blocks of the same color, you will still need to search for the right form and size.
Yet, if you only sort by color, finding the required form and size within that heap might still be easy enough and you would save the time spent for sorting by color, form and size beforehand.
In this case you can either sort by color, form and size or only by color.
To figure out what is best, try out what makes your end-to-end process more efficient. An easy way to figure this out would be to stop the time for sorting by color only and then building the car, and then stop the time for sorting by color, form and size and then building the car. Whatever is quicker is more efficient.
You might consider other factors, too, like “What is more fun? Searching during the build process or searching and sorting beforehand?” Having fun might increase your creativity, so it’s not a given that efficiency is the winning criteria in every situation.
What can we learn from this little example? It shows us that sorting criteria depend on purpose.
This means we first need to understand for which purpose we want to put structure into parts of our organization, and then we can define the criteria which serve that purpose best.
I’ve seen some domain design processes, where the purpose of the design was not clear. If it’s not clear, it’s not useful, so think about purpose before you start designing.
Domain Design for Product Teams
In Domain-driven Design and Scrum-based product organizations our goal is to design teams, which can work on encapsulated business domains, which have all the complexity within their domain and little dependencies on the outside world.
Domains can have subdomains, e.g. an e-commerce domain can have subdomains like product listings, order process, delivery, etc. as subdomains, for which solutions can be developed by dedicated teams.
If our goal is to have autonomous teams, we try to design domains, where most communication can happen within that domain to take decisions, describe processes, etc. The foundation of domain-driven design therefore are business domains.
When designing domains, in many environments a conflict arises: if the teams want to be as autonomous as possible, they have to build the whole solution themselves. This means, that teams end up building redundant solutions for login mechanisms, logging, monitoring, etc.
This costs time and money, so teams decide to share some resources like identity and access management, runtime environments, gateways, CI/CD pipelines, etc. As long as these resources have stable and well-documented APIs and are reliable, available and adaptable, this kind of dependency does not hurt much.
But what happens if the shared resource requires lots of complex inter-team communication, lets the teams only test and deploy all solutions as a whole? That would slow down development instead of accelerating it.
Here the key is to balance autonomy with efficiency in a way that works best for your company.
Overlapping Domains
As mentioned above, in a product-oriented organization with strong customer-focus and agile development approaches the purpose of domain design is creating autonomous teams.
This allows scaling your development by adding as many teams as you like without losing much speed, and with the ability to scale individual solutions independent from other solutions. And it allows shortening times-to-market.
Other domains in your company could be designed to serve other purposes. The challenge here lies in the fact, that within a domain complex communication takes place, in between domains less communication is required.
If domains overlap, complex communication is everywhere and slows down your company.
So let’s say you have five relatively autonomous Scrum teams working on five different applications.
Each team works on a separate business domain and mainly communicates with its business counterpart and within the development team.
Now the Enterprise Architecture team shows up and says all five teams belong to the domain “Product Development Architecture” and the EA team wants to install quality gates, architecture guidelines and principles and hard-wired processes for architecture development.
This would create lots of communication overhead between the Scrum teams and Enterprise Architecture.
At the same time your Security department wants to establish better processes to make your solutions more secure, and again they come with quality gates, processes and people.
Governance might want to do the same, and sooner or later all these overlapping business, security and governance domains create so much communication overhead, that your next release would take place in such a far future that you start thinking becoming an agile company is slowing you down so much that you want to go back to good old waterfall planning…
To reduce the risk of too much communication overhead, you need to find an organizational approach for your company, which balances all the various domain purposes of your various stakeholders.
Company-wide structuring departments like Enterprise Architecture, Governance, Security, etc. can define non-functional requirements for products or set up communities or guilds to establish common goals, standards and principles, so that the teams can preserve their autonomy as much as possible and still provide the quality required by EA, governance, etc.
Of course this depends on many factors like compliance requirements in your business segment, etc.
Conclusion
Yes, I know, I have not explained how to design a domain in detail.
Yet, I hope it became clear that different departments have different interests and therefore might design overlapping domains, which can be an organizational challenge for your company.
Finding a good organizational structure balancing all the conflicting requirements of different departments is a matter of collecting, evaluating and assessing their requirements first, so that you can come up with a solution which best matches your company’s strategy.
Remember that domain design depends on the purpose of your domains. Define your goal first, then the criteria to create the domains which help you reach your goals.