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. As a result, the need to find solutions to this problem is one of the most important solutions before even coding. Clean Architecture is one of the solutions that aim to solve this problem.

Clean Architecture is focused on breaking up of concerns from business logic. This means 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.

Use Case.

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.

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 Dependancy 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.

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.

All of these concepts within one diagram.

Published by Mark

I have worked within the mobile software industry for a better part of a decade and it's something that I am very passionate about. From the proof of concept stage to the full app release stage, I find all the stages between exciting and exhilarating. Throughout my career, I have been a key resource on the projects that I have been assigned to, and help other teams get to better outcomes. In my current role, I'm the Technical lead, Architect, and Software developer. I am a part of all aspects when delivering solutions as well as being able to provide proof of concepts that allow organisations to make great customer focused solutions.

Leave a comment

Your email address will not be published. Required fields are marked *