Question 1

How do you structure a Flutter project?

Accepted Answer

Start with two layers: UI (widgets plus the object holding screen state) and data (repositories plus services). State the rule plainly: the UI never calls HTTP directly — it asks a repository for a domain object. Dependencies always point UI → repository → service, never back. I split folders by feature rather than by type: on a forty-screen app, one change touching four distant folders is a real pain. Close by saying when more layers are justified: I add a use case layer when business rules are genuinely complex, but on simple CRUD it would be pure boilerplate.

Question 2

Why do you need the repository pattern?

Accepted Answer

Three concrete reasons. (1) Testing — if the repository is an interface, tests supply a fake and the screen is tested without a network, precisely and fast; that is the biggest practical win. (2) Changing the source — REST today, GraphQL or an offline cache tomorrow, with the UI untouched. (3) Cache and merge policy in one place — the "read local first, then refresh from the network" rule lives in the repository instead of being repeated on every screen. Add that the pattern is not always warranted: in a two-screen prototype a direct API call is fine and the extra abstraction is a cost.

Question 3

Do you organise folders by feature or by type?

Accepted Answer

By feature. Splitting by type (lib/models, lib/screens, lib/services) looks tidy on a demo but hurts as the app grows: working on one feature means hopping between four folders, a team collides in the same directories, and removing a feature or extracting it into a package becomes hard. With a feature split, features/orders/ contains data, domain and presentation subfolders, so a change stays in one place. I keep a core/ folder for shared concerns. This is a maintenance decision rather than a technical one, and it scales with project size.

Question 4

Should you apply Clean Architecture in Flutter?

Accepted Answer

A balanced answer is expected. The valuable idea in Clean Architecture is the direction of dependencies: inner layers know nothing of outer ones, and that holds up well in Flutter. But the full canonical form — entities, use cases, repositories, data sources, each with its own model and mapper — often costs more than it returns on small and mid-sized apps: adding one field means editing five files. My approach is to start with the two layers from the official Flutter guide and add a layer when a need appears. Building the architecture up front "just in case" is the most common form of over-engineering here.

Layer	Responsibility	What it must NOT know
Widget	Displaying, forwarding events	The API's JSON shape or HTTP status codes
ViewModel / Bloc	Managing screen state	The networking library (dio/http)
Repository	Choosing the source, cache policy	Widgets or `BuildContext`
Service	Talking to one source (API, DB)	Business rules

Project architecture and layers

📚 Sources and documentation