Which architecture is most suitable for Flutter? Feature-first or Layer-first
One of the first decisions we must make when developing a large-scale application is how to structure a flutter app.
An efficient Flutter file structure helps you achieve great scalability and code maintainability, which is crucial for large-scale apps. Furthermore, a well-structured Flutter project allows team members to work on different parts of the app simultaneously without any clutter.
Hence, here we are investigating the two most used approaches for flutter project structure: feature-first and layer-first.
We will examine their drawbacks and common dangers when attempting to implement them in real-world applications. And we’ll conclude with a clear, step-by-step strategy for structuring your project while avoiding costly errors.
Flutter Project Structure in Connection to App Architecture
In practice, we cannot select a project structure until we have selected an application architecture.
This is due to the fact that app architecture requires us to design distinct layers with distinct boundaries. And these layers will appear as folders someplace in our project.
Obviously, if we are only developing a one-page application, we can place all files in a single folder and call it a day.
But, how can we organize all of our files in a consistent manner once we begin adding more pages and have to deal with many data models?
For that reason, a feature-first or layer-first methodology is frequently employed.
So, let’s dive into these two methodologies and discover which one is better.
Layer-first (features inside layers)
To keep things simple, let’s assume the application has two features.
Using the layer-first methodology, our project structure might look like this:
‣ lib
‣ src
‣ presentation
‣ feature1
‣ feature2
‣ application
‣ feature1
‣ feature2
‣ domain
‣ feature1
‣ feature2
‣ data
‣ feature1
‣ feature2
‣ lib
‣ feature1
‣ feature2
This is a “features inside layers” strategy since we don’t put our Dart files directly inside each layer but instead make folders inside them.
With this method, we can put all the necessary Dart files inside each feature folder to make sure they are in the right layer.
And if we want to add feature3, we need to put a feature3 folder inside each layer and continue the process. ‣
Drawbacks of layer-first
This method is easy to use in reality, but it doesn’t work well as the app grows. For any given feature, files from different layers are far away from one another.
And this makes it harder to work on individual features because we have to keep jumping to different parts of the project.
Feature-first (layers inside features)
The feature-first approach claims that for every new feature we add to our app, we need to make a new folder. And inside that folder, we can make subfolders for each layer.
Using the same example as above, this is how we would set up our project:
lib
‣ src
‣ features
‣ feature1
‣ presentation
‣ application
‣ domain
‣ data
‣ feature2
‣ presentation
‣ application
‣ domain
‣ data
‣ data
This method makes more sense because all the files for a certain feature can be seen at once because they are all grouped by the layer.
Compared to the layer-first method, the feature-first approach has the following pros:
• We can work on just one folder whenever we want to add a new feature or change an existing one.
• If we want to get rid of a feature, we only have to get rid of one folder
So, it looks like the feature-first method is the clear winner.
But in the real world, things are not so simple.
Feature-first isn’t about the user interface (UI)!
When we focus on the UI, we begin to believe in a feature as a single page or screen in the app.
But when it comes time to put the presentation, application, domain, and data layers inside them, it is hard because some models and repositories are shared by multiple pages, like the product page and the product list.
So, you have to make top-level folders for services, models, and repositories:‣
should this go here?
When implemented correctly, feature-first has numerous advantages over layer-first.
After constructing a 10k LOC eCommerce application with it, we will be convinced that this strategy is sustainable and should perform well with larger codebases. Obviously, while developing very large applications, we will face additional limitations. And at some time, we may need to combine alternative ways or perhaps split the software into multiple packages that reside in a single monorepo.
