Briefly about Clean Architecture

Image is worth more than 1000 words

The image above can tell you everything, but below is small description.

About Clean Architecture

It is a principle that has been propagated by Robert C. Martin (a.k.a Uncle Bob) to mix other architecture such as:
- Hexagonal Architecture (a.k.a Port and Adapters)
- Onion Architecture
- Screaming Architecture
- Data, context, and interaction Architecture (DCI)
- Boundary Control Entity Architecture ( BCE )

As Uncle Bob found out, all these architectures are similar and have separations. They are divided by software layers and each architecture has a layer for business logic and interfaces.
Therefore this architecture produces systems that are:

Independent of Framework. The architecture does not depend on the existence of some library of feature laden software. This allows you to use such frameworks as tools, rather than having to cram your system into their limited constraints.
Testable. The business rules can be tested without the UI, Database, Web Server, or any other external element.

Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.

Independent of Database. You can swap out Oracle or SQL Server, for Mongo, BigTable, CouchDB, or something else. Your business rules are not bound to the database.

Independent of any external agency. In fact your business rules simply don’t know anything at all about the outside world.
These all are very nice advantages to use this architecture.

The Dependency Rule

This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle

Entities

Entities encapsulate Enterprise wide business rules.

Entities are the business objects of the application. They encapsulate the most general and high-level rules.
They are the least likely to change when something external changes. For example, you would not expect these objects to be affected by a change to page navigation, or security.

Use Cases

The software in this layer contains application specific business rules.

These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case.

We do not expect changes in this layer to affect the entities.
We also do not expect this layer to be affected by changes to externalities such as the database, the UI, or any of the common frameworks.
This layer is isolated from such concerns.

Interface Adapters

The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web.

Presenters, Views, and Gateways (Repositories) are here. Data are converted in this layer and pushed back and forth through use cases and entities.

In this layer, you need to expect Adapters :)

Frameworks and Drivers.

The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc.
Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards.

Only Four Circles?

No, the circles are schematic. You may find that you need more than just these four.
However, The Dependency Rule always applies.

Crossing boundaries.

We use the Dependency Inversion principle
If your Presenter wants to use a Use case, he needs to use an interface to call it.

Use Case Output => interactor => Use case input

What data crosses the boundaries?

Use simple data structures as Data Transfer Objects (DTO) to transfer data through the layers.
You use it instead of the Resulting Data structure from Database (ResultQuery)

Uncle Bob's Conclusion

Conclusion

Conforming to these simple rules is not hard, and will save you a lot of headaches going forward.

By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies.

When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss.

My Experience without Clean Architecture

I still gather my experience in this architecture, however, I have written some features in this architecture.
I remember when we established a common interface between domains. Me and my team colleague wrote this code and it worked as we expected.
Some refactoring was needed because, as we found out later, we should use the same use case, the base of logic was stable and separated behind a stable interface.
Which helps us even if we don't know too many details about the partner's code.