We are fans of Clean Architecture for constructing software systems. It provides a solid foundation and guard rails to make sure your architecture doesn’t become tightly coupled, complicated and hard to understand.

What Is Clean Architecture?

Clean Architecure provides a blueprint for building systems that are easily extensible, adaptable and testable. Logically systems are layered, like an onion with higher level abstractions in the center of the architecture. As you move outwards in the layers the objects become more conrete and lower level. One important this to notice about the onion is that inner layers are not allowed to know about outer layers. The dependencies flow inward. So Use Cases don’t know about concrete types that implement the contracts defined in the Use Cases.

Use Case Layer

This is where the objects and functionality related to the problem domain are defined. This should be in the language of the domain, not the technology used. For example a system for tracking appointments at a doctors office would have objects named ‘Patient’ and ‘Appointment’ not ‘Database’ or ‘View’.

Great share should be given to make sure this layer has zero dependencies. Other layers in the system should depend on the Use Cases.

Datasource / Gateway Layer

Access to the outside world and datasources. This could be on device or remote databases, API gateways & cloud platforms. Typcially this layer will adapt it’s functionality based on contracts defined in the Use Case Layer.

Presentation / UI Layer

Handles transformation of domain objects into view models for presentation on screen. Also may handle sorting, filtering etc.

Composition Root

Responsible for composing objects from the various layers via dependency injection. Knowledge of specific concrete types lives in this layer. All other references in the system are via abstract contracts (protocols or interfaces) defined in the Use Case Layer

Conclusion

CLEAN Architecture is time tested and allows to a system to scale to any size while managing complexity.