More posts by this author
Head of iOS Department at Triare
How to implement modular architecture – and why it’s worth it.
On our latest Mobile Meetup, TRIARE’s Mobile Architect Olexandr Krugliak has shared some insights about modular architecture.
We’ve comprised key takeaways: how it differs from monoliths, pros & cons, and how modules are created.
Modular architecture is a set of functions that do not directly depend on each other. They can communicate and interact, but each of them remains easily replaceable.
The notion of modularity is easiest to explain in this example. Imagine that you have to move a bulky painting. Would you agree it’s easier if the painting was a take-apart? When assembling the piece, you could even replace or remake some sections. That’s the difference between the monolithic (bulky painting) and modular (puzzle) approach.
Monolithic architectures are hard to maintain. You will have to change an inter dependable code every time the client asks for updates. Dividing work gets complicated, while functional testing affects many dependencies.
In addition, the choice of architecture will highly depend on the qualification of a team. If the project is large and/or evolving, you will probably need Viper, but Juniors will hardly grasp it.
If you want more details on monoliths, here’s an overview of frequently used architectures in custom app development. We compare monolithic MVC, MVVM, and MVP and a modular Viper with recommendations on when to use each.
Now, let’s talk about modular design and why we put it among the best mobile app development practices.
We have taken on projects built on various architectures. Also, developers make rotations between them every so often. On monoliths, areas of responsibility are not explicit. Legacy projects are bursting at the seams.
These factors led us to modules, code standardization, and the habit of writing and reading code correctly. The seams were taken out in separate modules, and problems with functional tasks were solved in isolation.
We have reduced the amount of extraneous code and delineated areas of responsibility. A unified approach to writing code and docs reduced stress and helped a lot with onboarding.
However, different modules can be developed with completely different approaches. No different architecture or third-party libraries will break the main project. This contributes a lot to a speed of development and a sense of freedom. As well as safety: a mistake inside one module will not affect the rest of the project.
Modules help iterations. Each new project has a ready-made foundation. We create a project on the outlines of the interaction between modules and then accumulate the code inside each individual module. Not only does it increase the speed of development, but it also helps with vector changes (especially in large projects). Adjusting business value becomes as easy as replacing a module.
Each project may require a different set of modules and their variations. Here are the examples of modules we use in every project:
The structure is as follows: Navigation Router with a Navigation Module inside, which includes Navigation Controller, and Navigation Module View Controller. Navigation Module can branch into additional Navigation Modules.
All of these parts communicate via NavigationModel. It consists of the initiating View Controller and functions as a builder of Navigation Controller.
Launch of the NavigationModule:
We created this simple module to speed up the process by configuring the general style of an app, visualizing xib files, and using ready-made UI sets.
The module includes colour styles, font styles, app styles, UI elements. One simple example is ButtonStyleProperties, which includes all the changeable things. (Hack: if you get a single Figma file with all the styles and properties, it is easily transferable into the project and can be visualized through xib files).
This module was created to reuse the existing code and try testing DI in our modules.
Making a call:
Remember that the internal implementation of a module can be whether simple or complex, but the external use should always remain simple.
After creating six modular applications and 10+ modules, we can acknowledge the pros of a modular approach to app development: