Feature-First Folder Structure and Melos Monorepos
Organize features as independent packages and manage them with a Melos monorepo.
Why Feature-First?
As a Flutter app grows, the classic layer-first structure (top-level screens/, widgets/, models/, services/) starts to hurt. To touch one feature you jump across five folders, and unrelated teams collide in the same files.
Feature-first flips this: the top level is organized by business capability (auth, cart, profile), and each feature owns its own layers internally.
- High cohesion — everything for a feature lives together.
- Low coupling — features depend on contracts, not each other's internals.
- Scalability — a feature can later be extracted into its own package with almost no churn.
Anatomy of a Feature Folder
Inside lib/features/<feature>/ we mirror Clean Architecture's three layers. The domain layer is pure Dart with no Flutter or plugin imports, which is exactly what makes a feature easy to extract later.
A typical auth feature:
data/— DTOs, data sources, repository implementations.domain/— entities, repository interfaces, use cases.presentation/— widgets, pages, state (BLoC/Riverpod).
lib/
├── core/ // shared cross-cutting code
│ ├── error/
│ └── network/
└── features/
└── auth/
├── data/
│ ├── models/
│ ├── datasources/
│ └── repositories/
├── domain/
│ ├── entities/
│ ├── repositories/
│ └── usecases/
└── presentation/
├── bloc/
├── pages/
└── widgets/All lessons in this course
- Domain, Data, and Presentation Layer Boundaries
- Dependency Injection with get_it and injectable
- Feature-First Folder Structure and Melos Monorepos
- Either, Failure Types, and Functional Error Handling