Explanation & Project Structure
What to watch for
Start with the playlist's first lesson and focus on the architectural reasoning rather than simply copying the folder structure. Pay attention to why dependencies are directed inward and why business rules should not depend on Flutter widgets, HTTP clients, databases, or other external technologies.
The project is a Number Trivia application. The app is intentionally small, but it contains the same kinds of boundaries that appear in larger production applications.
Clean Architecture in Flutter
A useful way to think about Clean Architecture is to divide an application according to responsibility.
The domain layer contains the important business concepts and rules. It should be the most stable part of the system and should not know whether the application uses HTTP, SQLite, SharedPreferences, Flutter widgets, or a particular state-management package.
The data layer deals with external data. It knows how to communicate with APIs, local storage, and other infrastructure. It converts external representations into objects that the domain can understand.
The presentation layer deals with the user interface and presentation logic. In this course, BLoC is used as the presentation logic holder.
A simplified dependency direction looks like:
Presentation
|
v
Domain
^
|
Data
|
v
External systems
The important idea is that outer layers depend on inner abstractions rather than forcing the domain to depend on implementation details.
The three layers
A feature can be organized like this:
number_trivia/
├── data/
│ ├── datasources/
│ ├── models/
│ └── repositories/
├── domain/
│ ├── entities/
│ ├── repositories/
│ └── usecases/
└── presentation/
├── bloc/
└── pages/
The exact directory names are less important than the responsibilities behind them.
An entity represents a meaningful business object. A repository contract defines what the domain needs from data without saying how that data will be obtained. A use case represents an operation that the application can perform.
Why architecture matters
A small application can work perfectly with everything placed inside widgets. The problem appears when requirements grow.
Imagine that a widget directly calls an HTTP API. Later you need offline support, caching, another API, automated tests, or a different UI. The widget now contains networking, error handling, business rules, and presentation code. Every change becomes risky.
Clean Architecture creates boundaries so that these changes remain localized.
Testability
TDD becomes much easier when classes have small responsibilities and explicit dependencies. Instead of testing an entire application to determine whether a repository works, you can provide mocked dependencies and test the repository independently.
The architecture therefore supports testing; testing is not an unrelated activity added at the end.
Summary
The first lesson establishes the central idea: organize code around responsibilities and keep business logic independent from implementation details. The Number Trivia project is a vehicle for practicing these principles rather than the real objective.