Unlike any other frameworks keeping your code clean and maintainable becomes even truer in case of Flutter. Because In Flutter we write logics and UI code both in same language Dart, by doing so the business logic mix up with UI code. On one hand, it can be nice to build an app quickly with Flutter because Flutter boost the development process, but on the other hand, larger projects starts falling apart when we mix up the business logic with UI code everywhere. And then even best state management solutions like BLoC (subset Cubit) are not sufficient to allow for easily extendable codebase.
The Secret
What is the secret behind maintainable Applications? The Clean Architecture proposed by our friendly Uncle Bob, we all should separate code into independent layers that will depend on abstractions but not on concrete implementations.
How we can achieve that kind of independence in our code? From the layered image below, the horizontal arrows ( — > ) represent dependency flow. Example, Entities are fully independent, the only use cases depend upon Entities and so on.
Well, this may sounds a bit abstract like what are Controllers, Gateways etc. Everything will become crystal clear when we go forward and explore the Flutter Clean Architecture.
The Project we're going to build
In this project we will use Firebase as a backend service. And for state management solution we will use Cubit which is the subset of BLoC, and you can choose whichever you like. And Clean Architecture is not about using a particular state management solution.
Flutter Clean Architecture
Project Structure
The basic structure of our project looks like the image below. As I said we’re going to use this architecture on a bit different way it will not be similar to the Reso Coder’s Architecture. So we’re going to have a features Directory in which there will be three layers Domain, Data and Presentation.
Tip: To create clean architecture structure directly. In Android Studio you’ve to install a plugin of Clean Architecture. In VS Code you can install this VS Code extension.
Presentation
Note: In this presentation layer the logic holders like BLoC / Cubit will not going to hold too much logic inside but they will delegates all its work to the use cases.
Presentation Structure
We’re going to have the cubit classes inside the Cubit Directory and all the pages will be inside the Pages Directory and the same for Widgets
And Inside these directories there will be sub directories or files like in the image below.
Domain
Domain is the inner most layer which will only contain the core business logic (use cases) and business objects (entities). And again it will be totally independent of any other layer. Domain layer is completely independent but all the other layers like Presentation and Data will be dependent on this layer because there will be all the abstractions / contract classes.
Note: Use cases will be the classes that will encapsulate the business logic of a specific use case of the Application.
If you look at the Repository in the Domain layer with its fancy gradient, it is at the edge between Data and Domain layer, and is getting data from the Repository which is located in the Data layer. Now you might be thinking how Domain layer is independent? If its Repository is getting data from Data layer’s Repository?
As I said earlier in the Domain Layer there will be all the abstractions and contract classes. So In our Repository class which is in the Domain layer there will be the contract that what the repository will do. And its implementation will be inside the Data layer to fulfill the contract.
Note: Dependency inversion principle is the last principle of SOLID principles. It states that the boundaries between the layers should be handled with interfaces which are abstract classes in Dart.
Domain Structure
The Domain structure will looks like the image below
And Inside these directories there will be sub directories or files like in the image below.
Data
Now look at these models, the data sources are returning models instead of entities. But why is that? Well, the reason behind this is that transformation of the data like from JSON to Dart objects and from Dart objects to JSON or also in our case from Snapshot to Dart Objects and so on.
Data Layer has Repository Implementation (which is the contract in the domain layer and we’re implementing it here), and Data Sources one is Remote other is Local. So remote data source in our case is Firebase (cloud firestore) it also can be an API or other DB. And the local data source is for caching data locally in local storage, and the Repository will be the place where we will decide when to return the real data or already cached data.
Ultimately, we create Model classes and extends them with Entities (our business objects) with some more functionality like I said (from JSON to JSON and from Snapshot etc.)
Data Layer Structure
The Data Layer structure will looks like the image below
And Inside these directories there will be sub directories or files like in the image below.
Conclusion
So we got the fundamental structure of the folders for our Instagram clone. So we will begin to build UI first then we will cover the other stuff.
Hit the link below and subscribe to the channel and also not forget to press the bell icon to make sure you get notified whenever the new video is uploaded.
Instagram Clone Part 1
