Domain driven approach solves more problems in complex systems than I initially thought.
Recently I got to know the concept of cognitive load and if you haven't heard about it - I encourage you to continue reading.
Let's say you have a box with limited capacity. You want to fill it well with valuable items. The ones you don't need may be time to pass on to someone else. Makes sense? You probably even practice it with the annual wardrobe check.
How is our head different from this process? For me, it is an analogy that illustrates the mistake we often make - filling the box with unnecessary things.
And here we can return to the software development. Business wants to solve problems and sell these solutions. This is done by engineers who plan and code everything necessary to achieve business goals.
- Choose a technology and use it properly.
- Create the runtime environment, build a CI workflow, learn how to deploy the application, access the database, run async actions, etc.
- Understand business needs and implement them.
The list above is not accidental. The order of the points is in order from the most technical to the most business-oriented (we earn money here).
As the complexity of the system grows - there is a chance that there will be a problem with cognitive load - Team Topologies book (Matthew Skelton, Manuel Pais) well describes how it’s impacting the team’s performance, motivation, commitment and even changing the style of their work, turning the team into a group of individuals.
If we stop for a moment to think, we can conclude that the biggest cognitive load is generated by the domain. There is the logic of the application that introduces the most complexities, policies, strategies, problems, tricks to remember or even „temporary” workarounds.
DDD may be the first step in solving this problem. Since you are able to split one application into subdomains and divide the responsibilities into a wider group of people, as a benefit you get a less stressed, overburdened team that performs much better. As engineers, we think a lot about software architecture, design patterns, code quality, often forgetting something so important in my opinion.
Having a less busy team, there is a greater chance for bottom-up initiatives. Improving DevXP (the second point of our list) will result in more available time in the future for work on domain problems.
If this topic sounds interesting - see the book mentioned above. Very inspiring.