One of the hardest things to do is to make sure that a codebase is easy to understand. From a junior to a senior developer, making sure that the main concepts are passed on and understood is an up hill battle. Clean Architecture is a solution that aim to solve this problem.
Clean Architecture is focused on breaking up your app into logical components. This could mean breaking up services that connect to an outside data source and to displaying of the data that is fetched.
Main concepts of clean architecture are as follows.
A use case is a description of the way that an automated system is used. It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output. A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities.Use Cases – Clean Architecture by Robert C Martin
Repositories are used to allow Data Models to connect with use cases and supply information to then allow them to run their business logic, but also allows them to not be depended on using Dependency Inversion Principle.
The Dependency Inversion Principle The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies.DIP – Clean Architecture by Robert C Martin
Services are the details to the high level policy (Use case). Where the data is coming from, what data was required to get that information. What Authentication’s required and what response was received. Services allow for the underlying OS and API to gather the data for you and then returns them within the data layer model.
Once data has been returned from the service, it is up to the mappers to then map it to a domain model, as the Domain doesn’t (and shouldn’t) care about how it was received and in what previous format it was. It is then up to the Repository to then send up the domain model up to the use case.