Architecture Proposal

It is a basic and continuous flutter project to save and present my clean architecture proposal.

Ler em Português

Overview

Well, this proposal was based on Reso Coder Proposal and Flutterando proposal. I did some changes/improvements in both proposal considering some necessities, and of course, respecting the SOLID principles and the Clean Code.

The base-proposal branch is the clean proposal, it's just used only Dart/Flutter code without any external package, except the dartz package that only provide useful dart classes. (see Either class)

Explain

Here is the Uncle Bob's Clean Architecture Proposal

Note that the divisions and the arrows representing the dependency flow.

I follow the Reso Coder dividing the features in three layers according the diagram:

All features in my proposal follow the diagram's divisions.

In my proposal I tried to streamline a large amount of folders and files to avoid redundancy, but without wanting the principles, maintaining high cohesion and low coupling.

Speaking of loose coupling, the RestService class is the abstraction of a package for http requests, it knows the external package and all the datasources depend on it, so if the package for requests is replaced, only this class will have to be changed.

Folders

Now I'll explain the folders organization.

In the root of the project (lib folder) I put three folders, features, core and shared.

The core folder is for putting "immutable" classes. Classes that you won't be using often in your development work.
Ex: environment config, global services abstration etc.

The shared folder is for putting shared files for the whole project.
Ex: enums, entities, extentions, constants etc.

The features or modules folder is for putting all the features of the project.
Obs: Each module will be divided into three other folders referring to the three layers shown above in the image.

Layers

The three layers are: domain, data and presenter.

The domain contains all business rules. It says what the module does.

The data layer tells how the module executes its tasks.
All implementation, connection is done in this layer.

Note that: The repository on the image/diagram belongs the domain and the data layer, so the abstraction is in the domain, but its implementation is done in the data.
I use the repository implementation to handle possible datasource errors.

Finally, the presenter layer takes care of the view, widgets and presenter logic. It only knows the module's use cases.

You can see a real project example in my Todo List App.