DataSource - Feelynx/flutter_clean_architecture GitHub Wiki

The DataSource interface defines the contract for accessing remote or local data sources. In the context of Clean Architecture, Data Sources act as the gateways through which the data layer interacts with external systems, such as REST APIs, databases, or local storage. The primary responsibility of a Data Source is to provide methods for fetching, sending, or updating data required by the application, which is then passed through the layers up to the domain.

• Fetching Data: Data sources typically fetch data from external systems, such as remote servers (via APIs) or local databases. The data retrieved is often in the form of DTOs, which are then converted into entities to be used by the domain layer.
• Separation of Concerns: A Data Source ensures that data-related logic, such as making network requests or querying databases, remains separate from the business logic of the domain.
• Return DTOs: Data Sources are responsible for interacting with data in its raw form, and they return Data Transfer Objects (DTOs) that represent this raw data. These DTOs can later be converted to entities as they flow through the application layers.

In this example, AuthRemoteDataSource is an abstract class that defines methods for interacting with a remote authentication service. These methods handle various authentication tasks, such as retrieving user session information or refreshing user tokens.

abstract class AuthRemoteDataSource {
  Future<UserSessionResponseDTO> getUserSession(UserSessionRequestDTO authRequestModel);
  Future<RefreshUserSessionResponseDTO> refreshUserSession(RefreshUserSessionRequestDTO refreshTokenRequestModel);
  Future<UserDTO> getUser();
}

The above interface defines the required methods that an authentication data source should implement. It returns DTOs to represent the response from the remote API, adhering to the separation of concerns principle in Clean Architecture.

The DataSourceImpl class is a concrete implementation of the DataSource interface. It interacts with the actual data layer (e.g., via HTTP clients or database queries) to perform the actions defined in the interface. This class hides the details of how data is fetched or updated, making it easy to swap out implementations (e.g., switching from a REST API to a GraphQL API) without affecting the domain or presentation layers.

In this example, AuthRemoteDataSourceImpl implements the AuthRemoteDataSource interface by interacting with an API client (AuthApiClient) to fetch and return data.

class AuthRemoteDataSourceImpl implements AuthRemoteDataSource {
  final AuthApiClient client;

  AuthRemoteDataSourceImpl({required this.client});

  @override
  Future<UserSessionResponseDTO> getUserSession(UserSessionRequestDTO authRequestModel) {
    return client.getUserSession(authRequestModel);
  }

  @override
  Future<RefreshUserSessionResponseDTO> refreshUserSession(RefreshUserSessionRequestDTO refreshTokenRequestModel) {
    return client.refreshUserSession(refreshTokenRequestModel);
  }

  @override
  Future<UserDTO> getUser() {
    return client.getUser();
  }
}

In this implementation:

• The AuthRemoteDataSourceImpl class uses an injected AuthApiClient to perform actual API calls.
• It provides concrete implementations for all the methods defined in the AuthRemoteDataSource interface.
• It acts as the layer that abstracts away the network communication details, ensuring the domain layer remains unaware of the underlying API structure.

The DataSource interface defines a contract for fetching and manipulating data, allowing the data layer to interact with external systems in a structured way. The concrete DataSourceImpl implementations handle the actual data interactions, such as API calls or database queries, while maintaining the separation of concerns between layers. This pattern is essential in Clean Architecture to ensure that data access logic remains decoupled from the domain and business logic.