flutter-app-architecture

Separate the app into a UI layer (Views and ViewModels) and a Data layer (Repositories and Services), adding a Domain layer only for complex logic. State flows down from Data to UI while events flow up, and only adjacent layers may communicate.

A Repository is the single source of truth and the only class allowed to mutate its data. It handles caching, error handling, and data refresh, transforming raw data from Services into domain models for ViewModels to consume.

Add use cases only when logic is complex, does not fit cleanly in the UI or Data layers, or is reused across multiple ViewModels. A typical case is merging data from multiple Repositories, such as filtering bookings by the current user.

Supply dependencies via constructors and define abstract interfaces for repositories so implementations can be swapped in tests. For example, a BookingRepository interface with a BookingRepositoryImpl concrete class allows mock injection during unit testing.

No, the UI layer must never access a Service directly. Views communicate only with ViewModels, which retrieve data from Repositories, which in turn call Services, preserving unidirectional data flow and separation of concerns.