Project Structure

Generated app

.azuredevops/

The folder contains configuration files for integrating your project with Azure DevOps. This folder typically includes YAML pipelines, configuration scripts, and other files needed to automate CI/CD processes, manage builds, run tests, and deploy your application.

.dart_tool/

This folder is automatically generated by Flutter and Dart to store internal tools and configurations.

You should not modify anything in this folder, as it is managed by Flutter and Dart themselves.

.env/

This folder stores environment variables for particular flavors. It is commonly used to store configuration settings such as API URL, app name, or other data.

.fvm/

This folder is related to Flutter Version Management (FVM). FVM allows you to easily manage multiple versions of the Flutter SDK, making it easier to switch between versions on a project-by-project basis.

.vscode/

This folder contains configuration settings for Visual Studio Code. The files within this folder allow for customized settings for your Flutter project.

android/

This folder contains the Android-specific code and configurations.

build/

This folder contains generated files and build outputs. It is automatically managed by Flutter and should not be edited manually.

coverage/

This folder is used to store code coverage reports generated by testing tools. Code coverage reports show how much of your code is covered by tests.

integration_test/

This folder is used for writing integration tests in Flutter. Integration tests are used to test the complete application or a feature, simulating real-world scenarios.

ios/

This folder contains the iOS-specific code and configurations.

lib/

This is one of the most important directories in your project, as it contains the Dart code for your application. The structure within this folder can vary depending on your architecture, but typically includes:

• main.dart: The entry point for your Flutter application.
• Other subdirectories or files to organize your features.

linux/

This folder contains the Linux-specific code and configurations.

packages/

This folder typically contains packages and dependencies that are local to the project, managed through pubspec.yaml.

reports/

This folder is used to store various reports such as test reports, coverage reports, and other project metrics.

services/

This folder may contain services such as API integrations, or other related code that interacts with your business logic.

test/

This folder is for unit and widget testing. Test files typically end with _test.dart and contain test cases for specific features or parts of the app.

tool/

This folder can contain various developer tools or scripts that are used to automate tasks like code generation, formatting, or other developer utilities.

web/

This folder contains the web-specific code and configurations.

windows/

This folder contains Windows-specific code and configurations.

.fvmrc

The file specifies the Flutter version to be used for a project, ensuring consistent development environments across different team members and simplifying version management with Flutter Version Management (FVM).

.versionrc.js

TODO

melos.yaml

Melos is a package for managing monorepos in Dart and Flutter projects. The melos.yaml file defines how your monorepo is organized, including the packages and commands that need to be run.

pubspec.yaml

This is one of the most important files in your Flutter project. It defines your project's dependencies, assets, and configurations.

analysis_options.yaml

This file is used to configure static analysis rules for Dart code. It uses eit_lints rules to ensure your code follows certain style and best practices.

dart_test.yaml

This file configures how tests should be run in your project, such as setting timeouts and other test-related settings.

pubspec.semver.js

Script for updating the application's semantic versioning.

Flutter App Structure (lib)

config/

The folder contains configuration files that handle critical infrastructure and application-wide settings. These configurations help set up key functionalities such as dependency injection, routing, and other configurations. Below are the common components found in this folder:

• Dependency Injection: Controls the instantiation and lifecycle of services and classes throughout the app.
• Routing: Oversees navigation and routing, specifying available screens and paths within the application.
• Theming: Handles the overall visual styling and theme management for the app.
• Others: config/ should contains resources and utilities shared across the entire application.

features/

This folder is organized into sub-folders, each representing a specific feature or module of the app. This structure helps in maintaining separation of concerns and scalability.

Feature Structure

Each feature in the features/ folder follows a Clean Architecture approach. The feature folders are divided into specific sub-folders to ensure a clear separation of concerns. These common sub-folders include application, config, domain, infrastructure, and presentation. Here’s a breakdown of each sub-folder:

application/

This folder contains use cases and services that implement the business logic of the feature. It defines what the feature should do, following the "application layer" in Clean Architecture. This layer coordinates the flow of data between the UI and the domain layer.

config/

This folder for each feature contains feature-specific configuration settings such as feature-specific routing, dependency injection setup, or other initialization logic. It ensures that each feature is self-contained and manages its own configuration needs independently from other features.

domain/

This is the core layer of each feature, holding the business rules and entities. It is independent of any other layer and can be reused across different implementations. The domain/ folder contains:

• Entities: These are the core business objects (models) that represent data and rules for this feature.
• Repositories (interfaces): Defines contracts for the data layer. The repository interfaces are implemented in the infrastructure/ layer, while the domain layer remains agnostic to data sources.

infrastructure/

This folder is responsible for the concrete implementations of the repository interfaces declared in the domain/ layer. The infrastructure/ folder typically includes:

• Data sources: External data sources (e.g., API clients, databases).
• Repository implementations: Concrete classes that implement the repository interfaces and interact with the data sources to fetch or send data.
• Mappers: Convert data from the infrastructure layer (e.g., JSON) to domain entities and vice versa.

presentation/

This folder contains the UI components and state management for the feature. The presentation/ layer is responsible for rendering the UI and interacting with the application layer to trigger use cases. It typically includes:

• Widgets/Screens: UI components such as Flutter widgets.