Member-only story
Using Clean Architecture in Flutter
PS (Pre-article statement): This article is based on what I understand from clean architecture and my observations on its application in the mobile app development world. So, if you see any issue in my way of using clean architecture, please kindly inform me :)
First of all, if you don’t know what clean architecture is and why it’s a good thing to implement, please first check Uncle Bob’s blog post.
If you don’t still get what it is, there are many articles out there online and you can go through a couple of them. However, in short, the goal of using clean architecture is to have a codebase:
- That does not depend on some framework or library, and
- In which business rules (use cases and entities — these are the inner layers of our architecture) do not depend on user-interfaces, databases, web servers, or some external devices (and these are the outer layers).
In other words, dependencies can exist only from outer to inner layers. We put more general stuff in inner layers and are more likely to change stuff in outer layers. As a result, we can easily replace whatever in outer layers easily when we need and without affecting our core logic. And this core logic always stays testable as it’s independent of external factors.
OK, that’s enough for the explanation part! I know these words don’t mean much without showing a real-world example. Therefore, it’s time to get into how I use clean architecture in a Flutter app.
Main project
First of all, our app’s overall architecture is as follows:
The main/root project has three modules (Flutter packages) in it: presentation, data, and domain. Presentation and data modules are the outer layers of clean architecture, whereas the domain module corresponds to inner layers. That’s why the first two depend on the third one. In the overall picture, our root project depends only on these three packages, nothing else.
In terms of code, the main project has just main.dart file under lib folder. Here, basically what we do is to…
