Functional decomposition is separating parts of your application into their own sections and allowing teams to develop these sections independently. Splitting the application by business capabilities and defining boundaries that enable teams to work independently is at the core of functional decomposition.
If you’re developing backend applications, one way to do functional decomposition is by splitting your monolith into microservices.
If you’re developing mobile applications, one way is by splitting your application into several frameworks and enabling teams to work within these frameworks.
The advantages of this approach are reducing communication overhead, easier maintenance of the small codebase, easy scaling, ease of deployment, replaceability, and resiliency. Communication between 4 people is way easier than communication between 20 people. As these small teams handle smaller codebases, they can deploy and scale easily. Whenever something goes wrong, it’s easy to replace the whole service.
Of course, it comes with disadvantages. Although small teams are independent in making decisions and moving fast, it becomes difficult to create developer tools and automate workflows when everyone chooses their tech stack and architecture. When the organization scales, automation, and developer tools become essential. With some technological governance, these issues can be minimized. For example, Netflix strictly uses Java, Python, and Javascript and developed tools for their teams to work effectively.
Other disadvantages are the difficulty of debugging and testing. As the number of independent modules grows, testing the integration of these modules becomes tricky. Testing the whole user journey becomes a challenge. It’s the same for debugging. Finding the root cause of a bug demands excellent monitoring and observability practices.
The last one I’ve experienced is the maintenance overhead. Teams create tiny modules, and each module requires maintenance. I would argue about starting a service to do only one thing. The overhead it creates is often more significant than the benefit it brings. One maintenance overhead is once you have an API definition, you have to maintain it for your clients. There are solutions, like API gateway, to solve the problem, but it will always be another thing to develop, deploy, and maintain. Also, the API gateway is coupled with multiple services and needs to be updated whenever there is an update in the services it is connected to.
The challenges of decomposing mobile apps and backend services are very different. Decomposing mobile apps often creates problems in dependency and release management. Decomposing backend applications create more points of failure and reduce resiliency. Although there are practices to reduce these risks, such as dependency inversion for mobile and chaos engineering for the backend, some challenges will always be unique to the tech stack and require knowledge in the area.
If you want to expand your knowledge in splitting monolith to microservices, I recommend reading Monolith to Microservices or Building Microservices, both by Sam Newman.
If you want to expand your knowledge in scaling mobile apps, I recommend reading Building Mobile Apps at Scale by Gergely Orosz. Although the book is not a technical deep dive, it gives great insights into the challenges you will face.
