Implementing Flutter Base - Part 2: Overall Architecture

I. Solving the overall architecture problem.

Continuing from the context part, now we delve into more details in the process of building the Flutter base.

First, we need to address the two most important questions:

• How to implement the Flutter base using which architecture, and how to organize the code?
• How to manage state effectively?

Do you wonder why I believe these are the top two issues that need to be understood and resolved first? In our company, there are many mobile app projects running simultaneously, and cross-team support is common. Most team members are new to Flutter. Therefore, making a decision about the overall architecture is extremely important. This will provide a shared vision and goal, allowing us to support each other as effectively as possible. Projects with a good architecture are also easier to maintain and troubleshoot.

Without further ado, let's dive into the details of the answers to the two questions:

• Architecture: It's Clean Architecture, organizing the code with a Layer-first approach combined with Feature-first.
• State Management: Using Bloc Cubit.

1. Architecture following Clean Architecture.

Once again, the familiar name Clean Architecture, a name that many in the IT industry have heard of. Along with it comes a lot of discussions: whether it's overly complex, whether it might not be necessary, everyone applying it differently, and so on. But surely those who have heard these discussions cannot deny the outstanding advantages it offers us: ease of maintenance, scalability, extremely effective layer separation, easy unit testing, and more.

2. State management with Bloc Cubit.

There are countless approaches to state management, and I chose Bloc and implemented the Bloc pattern from the early days of my exploration. The reason for this choice is that back when I was learning, I found that Bloc was excellent at separating business logic from the UI. This is something I highly value, as it's a practice I also emphasized when working with native platforms.

3. Combining Feature-first with Layer-first to optimize code organization.

And when implementing them, to organize the source code, I combine both Layer-first and Feature-first ???

Wait, what? Why combine both feature-first and layer-first?

If organized by feature-first: it's easy to manage each specific feature, but as a result, the code organization might become fragmented according to each feature. As you can see in the left-hand image, if there is shared processing logic among features, what happens? In most applications we work on, features often have many connections and are not perfectly separated for organization in this way.

As for organizing by layer-first: this is an approach where we can manage based on specific layers, each handling distinct tasks, which allows us to make the best use of the source code. But looking at the right-hand image and the real-life situation when we have to maintain a feature, it can be a nightmare to navigate up and down through the layers to read the corresponding files.

So, the solution of combining both approaches is something worth considering. I use layer-first for organizing data and business logic layers, and feature-first for managing source code with specific features for the presentation layer.

II.Project structure.

Everything we can see in the implementation of Clean Architecture is condensed in the diagram above.

Looking at it, we can clearly see the three most important layers:

• Presentation: containing UI and Bloc (This is the layer we will implement following the Feature-first approach). It's responsible for displaying and interacting with users.
• Domain: containing Use Cases, Entities, and Interface Repositories. It's responsible for handling business logic.
• Data: containing Impl Repositories, Models, and Data sources (local & remote). It's responsible for managing data for the application.

Corresponding to these main layers are the folders we will manage. In addition, I've created a utils folder, where I implement small base modules and convenient utilities.

When combined, we organize the code as follows: