Clean Architecture
Introduction
Disclaimer: Although this article will provide a feedback of Clean Architecture on a mobile app development, this is a general concept that can be applied to any software project.
Clean Architecture was first explicitly theorized in a book: Clean Architecture: A Craftman’s Guide to Software Structure and Design, 2017, Robert C. Martin (aka Uncle Bob). This is a theoretical guide for development teams about project structure, therefore it has many possible implementations.
It is the same principle as The Manifesto for Agile Software Development which only gives you guidelines and you can follow them in several ways (for instance SCRUM and KANBAN).
Motivation
Before explaining the rules and implementation of Clean Architecture, we have to ask ourselves one question: What do you expect from an app?
The answer is probably:
- Testable (with maximum code coverage)
- Maintainable
- Flexible (adapt to business, API or SDK changes)
- Easy to develop
- Independent
Regarding these needs, what does Clean Architecture has to offer?
- Keep development efficient over the time
- Ensure constant complexity whereas it usually raises with time ( which implies a productivity sink, unhappy developers and a need to hire more developers…)
- 100% testable code
Rules
If you are convinced by Clean Architecture’s promises, let’s check its basic principles.
Vocabulary
Here is the vocabulary that will be used in this article so that there is no misunderstanding:
View = Activity + Fragment + View
Entity = Model class
Use Case = Business feature
Repository = Class that centralizes data access
Separation of layers
This is the first rule. It simply asks developers to structure the project by splitting the code following this logic.
- Presentation = UI = View + ViewModel
- Domain = Business logic = Use Case + Entity
- Data = Repository + Database + SharedPreferences + Network calls…
Dependency Rule
The second rule is directly linked to the previous one, it gives you the way layers should interact together.
- UI and Data depend on Domain
- Domain is independent
The purpose of these rules is to ensure each layer as independent and reusable as possible. For instance, a repository is therefore easy to call from different domain classes and in different UI contexts.
REX
Context
The app I am currently working on illustrates well the pros and cons of Clean Architecture, is several years old and has a lot of features. Furthermore, many developers with their own vision have worked on it. That’s why onboarding is always very complex, you need to know the project to find anything you are looking for.
Trigger
A few months ago a new Android lead tech has arrived and he managed to get more time for technical tasks. After that the Android team started to work following Clean Architecture’s principles.
Drawbacks
- It is difficult to implement on an existing project whose architecture is chaotic
- Experienced developers with strong knowledge of Clean Architecture are required
- At the beginning the complexity of all tasks is increased
- Entities are duplicated since each model has its representation in all layers
Benefits
- Applying the rules requires developers to gather and ask questions about the right way to do things
- Clearing logic from UI allows a far more readable code
- Logic is only in use cases so you do not have to spend time searching for it
- Testing is easier
- More benefits will come (as I write this, we started a few months ago)
Conclusion
Clean Architecture has indeed a lot to offer and answers many software projects needs.
Even if it could seem perfect until there, you should keep in mind that this should not be applied to any project. Here are a few contraindications:
- As the implementation is long at the start, small apps should not necessarily follow Clean Architecture
- Apps that only display info from the server and have absolutely no logic do not need it either
- The complexity requires some experimented developers in the team
- If there is a short deadline, avoid this architecture as it is time-consuming at first, the benefits are long-term effects
Please always keep in mind that there is no magic recipe and each project has its own constraints to fulfill in order to choose an architecture.
