Clean Architecture is een set principes en richtlijnen voor het ontwerpen van software systemen op een modulaire, testbare en onderhoudbare manier. Clean Architecture adviseert scheiding van verantwoordelijkheden en onafhankelijkheid van componenten. Deze onafhankelijkheid wordt gerealiseerd door het gebruik van lagen. Elke laag heeft afhankelijkheden naar de eigen laag of lagen binnen de laag.

Het doel van clean architecture is dus onafhankelijkheid creëren. Bijvoorbeeld onafhankelijkheid van gebruikersinterfaces of databronnen. Deze onafhankelijkheid vergroot de testbaarheid en vereenvoudigt het onderhoud van applicaties. In implementaties van clean architecture zie je vaak de volgende lagen:

1. Web: de interface naar de applicatie.
2. Infrastructure: de koppelingen naar externe afhankelijkheden. 
3. Services: de business logica op applicatie niveau. 
4. Core: de domein objecten en business logica op domein niveau. 

In de onderstaande figuur staan deze lagen grafisch weergegeven met 3 cirkels. Het zijn als de lagen van een ui (De groente, geen user interface 😊). 

Web en infrastructure zijn afhankelijk van services. Web, Infrastructure en services zijn afhankelijk van de core. De core bevat geen afhankelijkheden. Bij kleinere applicaties en micro-services voegen software designers de Core en Services vaak samen tot een enkele laag.

In een clean architecture beschouw je databronnen niet als onderdeel van de business logica. Je beschouwt ze als onderdeel van het persisteren van data. De logica om databronnen te benaderen zit bij een clean architecture daarom in de infrastructure laag, niet in de core laag. 

In de volgende paragraaf gaan we hier dieper op in door het repository pattern te positioneren in een clean architecture.

Met Dependency inversion ontkoppel je de verschillende lagen in een clean architecture met behulp van abstracties.

Dependency Inversion Principle stelt dat ‘High Level Modules’ afhankelijk zijn van abstracties en niet van de implementatie. In voorgaand schema is de Orderservice afhankelijk van de interface class IOrderRepository en van de implementatie van de interface. Hiermee voldoet het ontwerp aan het Dependency Inversion Principle (DIP).

Dependency inversion zorgt voor ‘Loose-Coupling’ op de onderliggende classes en de gebruikte frameworks. Door deze loose-coupling kun je de business logica onafhankelijk van de databronnen testen.  Voor het testen maak je dan een ‘mock’ van de repositories om de werkelijkheid de simuleren. Als gevolg hiervan maak je het unit testen ook eenvoudiger. Vergeet niet dat je ook integratietests nodig hebt voor het testen van de communicatie tussen de lagen.  

Het gebruik van Dependency inversion vereenvoudig je met een Dependency Injection framework. Zo’n framework zorgt dat de juiste implementatie aan een ‘High Level Module’ wordt meegegeven. Niet als de concrete class maar de interface.