Clean Architecture w praktyce

Clean Architecture (Robert C. Martin) to wzorzec architektoniczny który separuje business logic od frameworków, UI i external dependencies. Dla MVP: nie implementuj wszystkiego, ale rozumiej zasady.

Główna idea Clean Architecture

Dependency Rule: Dependencies wskazują do środka, nigdy na zewnątrz.

• Core (Domain): Entities, use cases — zero dependencies
• Application: Interfaces, DTOs — zależy tylko od Core
• Infrastructure: API, database, UI — zależy od Application

Efekt: Business logic nie zależy od Flutter, Firebase czy żadnego frameworka. Można je testować bez UI.

Praktyczna implementacja (Flutter)

Folder structure:

• domain/ — business logic
  • entities/ — User, Product, Order
  • repositories/ — interfaces (abstrakcje)
  • usecases/ — LoginUseCase, GetProductsUseCase
• data/ — implementacje
  • repositories/ — UserRepositoryImpl
  • datasources/ — FirebaseDataSource, ApiDataSource
  • models/ — UserModel (DTO)
• presentation/ — UI
  • screens/ — LoginScreen, DashboardScreen
  • widgets/ — reusable components
  • providers/ — Riverpod state management

Przykład: Login Feature

1. Entity (domain/entities/user.dart):

• Pure Dart class, zero dependencies
• class User { final String id; final String email; }

2. Repository Interface (domain/repositories/user_repository.dart):

• Abstrakcja — "co" ale nie "jak"
• abstract class UserRepository { Future<User> login(String email, String password); }

3. Use Case (domain/usecases/login_usecase.dart):

• Business logic — walidacja, transformacje
• Używa repository interface, nie implementacji

4. Repository Implementation (data/repositories/user_repository_impl.dart):

• Konkretna implementacja — Firebase, REST API, etc.
• Implementuje interface z domain

5. UI (presentation/screens/login_screen.dart):

• Wywołuje use case przez provider
• Wyświetla rezultat

Dependency Injection

Jak połączyć warstwy? Dependency Injection.

Riverpod providers:

• userRepositoryProvider → zwraca UserRepositoryImpl
• loginUseCaseProvider → używa userRepositoryProvider
• UI używa loginUseCaseProvider

Łatwo zmienić implementację (Firebase → REST API) bez zmiany business logic.

Kiedy NIE używać Clean Architecture

• Proof of concept (1-2 tygodnie)
• Bardzo prosty CRUD (admin panel)
• Prototyp do wyrzucenia

Dla MVP produkcyjnego: użyj uproszczonej wersji (3 warstwy: domain, data, presentation).