CODEWITHSUNDEEP
architectureclean-architecture
Thieri
Thieri

Reputation: 213

trouble understanding clean architecture

I'm relatively new to the architecture concept of clean architecture. Unfortunately i have some understanding issues:

I understand the concept, that you should follow the the rule, that no inner layer can know anything about the outer layers and that you can only call the outer layer through a boundary interface.

Now let's work a simple thought experiment where a user inputs data that gets stored persistently: you have a UI (Webform, Console, ...) and the user inputs data. After an Event (e.g. submit) the controller calls an usecase (say 'PersistentStoreData') and we work our way downwards to the entity level. I'm somewhat fine with understanding this. But say we want to store the data to a database. The decoupling rule says no entity, usecase or whatsoever from the inner layers can know anything about the outer layers. Calls can only be made through an interface. But at one time there has to be an object instantiated that has the business logic for handling the database-request and surely you can't instantiate an interface. Which component instantiates this 'database-object'? Not the inner layers because of the dependency rule. The only other component would be the UI, but that makes no sense to me. Why should the UI know anything about the database?

Maybe a stupid question, but i can't get my head around this.

Upvotes: 0

Views: 618

Answers (2)

plainionist
plainionist

Reputation: 3573

The key patterns u want to have a look at are "repository pattern" and "unit of work" pattern.

The major difference between traditional layered architecture and Clean Architecture is that the interface to the repository is owned by the use case layer instead of the data access layer.

I started a blog series on How to implement Clean Architecture - maybe that helps u turning Clean Architecture into practice.

Upvotes: 2

Rob Conklin
Rob Conklin

Reputation: 9481

Take a look at IoC solutions. They really make a lot of this possible. By externalizing these dependencies you can code to the abstractions (interfaces). So instead of the database-object, you program to a repository interface. That way the calling class doesn't have to know about the repository details.

As far as what actually invokes the IoC infrastructure, that actually often is either a component of the framework you are using, or, in a case where you aren't using a framework, the UI talks to it to retrieve the use-case.

Upvotes: 0

Related Questions