Intro to App Architecture.
Hello everyone! 👋 Today I want to talk about the importance of architecting our apps and the main concerns around it. 🤔
What makes a good Architecture?
Maintainability
This is the main benefit of architecting our apps and libraries. A maintainable project means that its codebase is easy to (RUDT) Read, Update, Debug & Test. ☮️
Fighting Technical Debt
Technical Debt is the price that our projects pay for the wrong decisions. This can affect 1 or multiple RUDT points. Resulting in a more complex and/or error-prone codebase. 👊
- Good decisions can turn into bad ones with time. Don’t be afraid of change.
RUDT (read, update, debug & test) points → Extra notes:
Read: Read from an objective point of view. Don’t let your familiarness blur how readable something really is. 📖
Update: Change/update a functionality with the minimum side effects as possible.
Debug: Find out what is wrong with your code without spending more than necessary. 🐛
Test: Covering ALL outputs given all the possible inputs to future-proof existing features from future changes. Simplicity & black box testing help.
- Following the above should help writing maintainable code.
Before starting…
Architecture normally requires an initial research. Creating pet projects and trying out different architectures is a great approach. Remember to have in mind near future changes and extrapolating it to a bigger size project.
Although not everyone in your team needs to be fully involved around this initial research phase it is extremely important that information is shared when you meet checkpoints in order to show the positives, negatives, unknowns & also to get further feedback from other team members.
Once the architecture implementation kicks off it is also very important that the whole team understands and is on board with it. Creating a safe zone for the team to question, discuss and improve will help keeping the technical debt down and improve one or multiple RUDT (Read, Update, Debug & Test) points.
A starting point!
Good news, there are multiple architectures out there, even Google shared a guide to app architecture.
If you are new to app architecture you should definitely check it out. Some of my favorite parts:
A properly written Android app needs to be much more flexible as the user weaves their way through the different apps on their device, constantly switching flows and tasks.
App components can be launched individually and out-of-order and can be destroyed at any time by the user or the system.
It also contains a simple example with Activity + ViewModel + Repository. Pointing out the separation of concerns and that you should drive the UI from a model.
This approach is a good starting point to improve maintainability through decoupling from the framework but we can go even further with a popular architecture like Clean Architecture.
All of the architectures share 1 common goal which is improving maintainability and they all share some architectural principles in order to improve one or multiple RUDT (read, update, debug & test) points.
A popular architecture like Clean Architecture has the advantage that it has been adopted by many people, offering many learnings, resources & variants over the internet.
While many apps out there follow Clean Architecture or similar variants we can also see how bigger companies end up with a hand of architectures living together across different modules. This is not wrong at all and kind of expected. The important part is to keep up with good SOLID code & making sure it is a RUDT codebase.
Differences between Google’s guide and a simplified Clean Architecture approach.
- Dependency Inversion to improve how easy is to update your codebase.
- Layers/Modules with strict boundaries to encourage easier testing.
- Separation of concerns taken to the next level to improve readability.
Dependency Inversion
Depend on abstractions, not implementations. In simple terms, this means adding/depending on interfaces so we can easily switch the implementation and decouple our software modules.
Modules
Modules offer strict boundaries when compared to packages. Having to establish new dependencies from or to a module really helps thinking twice if it is the best thing to do.
Separation of concerns → Use case
The Use case/Interactor is a class where you extract the business logic out of your Presenter/ViewModel. This simplifies the Presenter/ViewModel because it only coordinates the view and executes the appropriate Use case. This encourages reusability and avoids god Presenters/View Models making everything easier to test.
That’s it, hope you liked it! Head up to Clean Architecture: Data Flow != Dependency Rule to discover some of the most common mistakes when adopting Clean Architecture.
