Clean Architecture Implementation

This project has been refactored to follow Clean Architecture principles and implement the BLoC pattern for state management. The refactoring aims to improve code organization, testability, and maintainability.

Architecture Overview

The application is organized into layers following the Clean Architecture principles:

lib/
├── core/                      # Core functionality used across the app
│   ├── di/                    # Dependency injection
│   ├── error/                 # Failures and exceptions
│   ├── network/               # Network client
│   └── usecases/              # Base usecase classes
│
├── features/                  # Features are organized into modules
│   ├── auth/                  # Authentication feature
│   │   ├── data/              # Data layer
│   │   │   ├── datasources/   # Data sources (remote, local)
│   │   │   ├── models/        # Data models
│   │   │   └── repositories/  # Repository implementations
│   │   ├── domain/            # Domain layer
│   │   │   ├── entities/      # Domain entities
│   │   │   ├── repositories/  # Repository interfaces
│   │   │   └── usecases/      # Business logic use cases
│   │   └── presentation/      # Presentation layer
│   │       ├── bloc/          # BLoC state management
│   │       ├── pages/         # UI screens
│   │       └── widgets/       # Reusable UI components
│   │
│   ├── user/                  # User profile feature
│   │   ├── data/
│   │   ├── domain/
│   │   └── presentation/
│   │
│   ├── exercises/             # Exercises feature
│   │   ├── data/
│   │   ├── domain/
│   │   └── presentation/

Layers

Presentation Layer

• Contains UI components and BLoC classes
• Responsible for displaying data to the user and handling user interactions
• Uses BLoC for state management

Domain Layer

• Contains business logic
• Includes entities, repository interfaces, and use cases
• Independent of any framework or implementation details

Data Layer

• Responsible for data retrieval and storage
• Includes repository implementations, data sources, and models
• Communicates with APIs, databases, or other external services

Key Components

Entities

Pure Dart classes representing the core business objects. They are independent of any framework or implementation details.

Use Cases

Represent a single business operation or action. Each use case has a single responsibility and is implemented as a class with a call method.

Repositories

Interfaces defining the contract for data operations. Implementations handle the actual data retrieval and storage.

BLoC (Business Logic Component)

Manages the state of the application by handling events and emitting states.

Dependency Injection

The project uses GetIt for dependency injection. The injection_container.dart file registers all dependencies:

// Register BLoC
sl.registerFactory(() => AuthBloc(...));

// Register Use Cases
sl.registerLazySingleton(() => LoginUseCase(sl()));

// Register Repository
sl.registerLazySingleton<AuthRepository>(() => AuthRepositoryImpl(...));

// Register Data Sources
sl.registerLazySingleton<AuthRemoteDataSource>(() => AuthRemoteDataSourceImpl(...));

Error Handling

Errors are handled using a combination of Exceptions and Failures:

• Exceptions: Thrown by data sources when errors occur
• Failures: Returned by repositories using the Either type from dartz package

Network Layer

The ApiClient class handles all network operations, providing methods for HTTP requests with proper error handling and authentication.

Backwards Compatibility

To maintain compatibility with existing code, the ApiService class has been maintained but refactored to use the new clean architecture components internally. This allows for a gradual transition without breaking existing functionality.

Benefits

• Testability: Each layer can be tested independently
• Maintainability: Clear separation of concerns makes the codebase easier to maintain
• Scalability: New features can be added without affecting existing ones
• Independence: Business logic is independent of UI or external dependencies

Next Steps

Continue refactoring other features to follow the Clean Architecture pattern, moving functionality from the old services to proper feature modules with appropriate layers.