O que é Clean Architecture?

O que é arquitetura de software ?

Que raio é isso? o que isso faz? Vamos começar com algumas definições do Robert Martin(Uncle Bob) onde ele diz que:

The goal of software architecture is to minimize the human resources required to build and maintain the required system
Ele disse aqui que:
O objectivo da arquitetura de software é minimizar os recursos humanos necessários para construir e manter o sistema

Tem outra do Martin Fowler

Software architecture is those decisions which are both important and hard to change
A arquitetura do software são as decisões importantes e difíceis de mudar

A arquitetura de software tem haver com organização, estrutura, design, relacionamento e comportamento.
Você já se deparou com a situação de escrever um software do zero, tava na empresa com um sistema legado e o chefe autorizou fazer outro, deu a carta branca. Tudo que foi decidido ali as tecnologias, servidores, frameworks etc.. são as decisões importantes e difíceis de mudar e vão acompanhar o time ou quem decidiu pelo cotidiano em quanto o software estiver no ar.
Essas decisões são afetadas pelo escopo do produto, valor que a empresa tem pra gastar seja com equipe, servidor etc.., volume de requisições, equipe é em sua maioria senior, pleno, junior, estagiários.., qual o prazo de entrega, é preciso levar em consideração todos os requerimentos.
Isso significa que por exemplo se a empresa tem 1 duzia de clientes e fizerem um sistema distribuído, com kafka, kubernets, banco de dados replicados etc.. será que foi a melhor decisão? olhando pra quantidade de clientes e pro gasto com servidores.
Cada tipo de software deve ter uma arquitetura diferente, um ERP é diferente de um jogo de RPG online, uma plataforma de streaming é diferente de um programa linha de comando e por ai vai.
Existem muitos tipos de arquiteturas cliente-servidor, monolítica,distribuída, orientada a serviço, orientada a eventos, serverless.. cada uma atende um determinado tipo de sistema de acordo com seus requerimentos.
Não é por que você usou clean arch em um sistema que você precisa replicar isso pra todos, e se você tiver um sistema que só faz cadastro do jeito que vem do browser, tipo uma newsletter você vai implementar todo conceito de clean arch, ou arquitetura hexagonal ou MVC só pra dar um save no nome e email ?

O que é Clean Architecture

É um modelo arquitetural orientada ao desacoplamento entre as regras de negocio da aplicação e os recursos externos como banco de dados, frameworks etc..
Então por exemplo o seu ORM vai ficar isolado em uma camada fazendo o papel dele que são as operações de banco de dados, salvar, atualizar trazer dados etc.., a entidade do ORM que geralmente representa uma tabela no banco de dados é diferente da entidade que fica na camada entity(domínio) que é onde estão as regras de negócios.

Como surgiu a Clean Architecture ?

O Bob Martin estava desenvolvendo esse software inclusive com o filho dele, que é um software onde você cria testes baseado numa wiki, onde você coloca os dados de entrada e saída e o programa dele tem uma engine que interpreta os dados e faz o bind com o algoritmo do teste.
No decorrer do projeto ele percebeu que quando ele olhava pra estrutura de pasta ele enxergava só o rails, e ele não queria ver o rails,ele queria olhar pra estrutura do projeto e enxergar o objetivo da aplicação(a estrutura não é só de pastas), ou seja a aplicação seguia os conceitos do rails. Então foi por isso que ele começou a perceber que estava dependente do framwork, do orm, das libs e ele começou a desenvolver o projeto isolando as regras de negocio, com testes e as camadas de caso de uso e entidades, deixando as outras coisas como orm, libs externas pra depois, dessa maneira ele focou no core do sistema apenas com testes.
Ele formulou a teoria de que o centro da sua aplicação não é o banco de dados, e não é um ou mais frameworks que você pode estar usando. O centro da sua aplicação é o caso de uso da sua aplicação.

Use Cases

The center of your application is not the database, nor is it one or more of the frameworks you may be using. The center of your application is the use cases of your application.

Caso de uso é o caso de uso da UML, onde você tem a analise das intenções do usuário, o que ele pretende fazer no sistema e então é mapeado os fluxos do que um determinado ator(usuário ou sistema) pode fazer, ex: fazer check-in, adicionar itens no carrinho etc..
o centro da sua aplicação deve ser esses casos de uso.
Mas até hoje é comum nas empresas quando vai arquitetar uma funcionalidade, o time já pensa primeiro como será a tabela no banco, é uma quebra de paradigmas pensar no caso de uso.
Os casos de usos contém a aplicação das regras de negócios, é aqui que você vai chamar as entidades.
Eventualmente você vai estar codando o seu caso de uso e vai perceber que precisa usar uma regra que esta contida em outro caso de uso, e vai vir o questionamento será que eu posso usar um caso de uso dentro do outro ? De forma bem direta, não. Quando isso acontecer é porque você encontrou uma regra de negocio independente e ela esta na camada errada, agora entramos na camada de entities.

Entities

Essa é a camada onde você vai modelar as regras de negócio independentes e que podem ser aplicadas em qualquer contexto, ou seja, são as regras(códigos) que eventualmente você estará usando em mais de um caso de uso. Essas entidades não se confundem com entidades dos ORM, são coisas completamente diferentes no caso as entidades do ORM são classes que abstraem as tabelas do banco de dados para criar um mapeamento de dados, são um data mappers: coluna X para atributo Y.
O que aconteceria se você adiciona-se dentro das entidades de regras de negocio funções do seu ORM.. por exemplo decorators, annotations etc..
Alem de quebrar o principio de single responsability, você ainda estaria gerando um alto acoplamento entre regras de negócios com sua infra estrutura a partir de uma lib externa de terceiro que é seu ORM, consegue perceber que dessa forma uma mudança la na sua tabela, uma coluna a mais ou a menos já impactaria nas suas regras de negocio.
Uma entidade deve ser uma classe? não necessariamente, pode ser um arquivo cheio de functions, isso depende da maneira que você e seu time esta codificando, mas se for uma classe acredito que fica mais fácil até pra seguir os princípios e padrões de orientação a objetos.

Interface adapters

Essa camada faz a conexão entre um dispositivo de I/O e os casos de uso, essa camada faz essa conversão de dados entre a infra(externo) com seus caso de uso.
Aqui esta toda a arquitetura MVC, controllers, middlwares, presenters etc..
Aqui que recebemos as requisições do usuário adaptamos colocamos dentro do DTO e passamos pro caso de uso, o caso de uso que orquestra as entidades, e depois recebemos um DTO de saída adaptamos e enviamos pra view.
Essa camada não conhece banco de dados, programa de mensageria etc..

Framewors and drivers

Essa é a camada mais externa onde esta a infra do projeto como banco de dados, redis,nginx, protocolos, kafka etc..
Mantemos essas coisas do lado de fora, onde podem causar poucos danos.

Conclusão

O que define as camadas? As camadas são definidas logicamente não confunda com criação de pastas. Você pode jogar tudo os arquivos na raiz do projeto, e ainda assim terá as camadas. O que vem a ser essa definição logica ? Respeitar a dependência, os arquivos das camadas mais internas não podem depender de quem esta nas camadas externas. Dizendo de outra forma quem esta fora pode depender de quem esta dentro. A direção de dependência de fora pra dentro.

Vantagens de usar

Isolam as regras de negocio
Definem camadas e suas responsabilidades
Tem fluxo de dependência ordenado e direcional
Favorecem testabilidade
São independentes de recursos externos
Facilita a evolução tecnológica

Links
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
https://engsoftmoderna.info/artigos/arquitetura-limpa.html
https://www.youtube.com/watch?v=NYoW-ycqbYk