Com base no livro Arquitetura limpa do famoso Uncle Bob e do video sobre esse tema do canal Código Fonte TV.

Link do livro na Amazon

Video Canal Código Fonte TV

Arquitetura Limpa:

• Tem como objetivo a separação das preocupações do software.
• Realiza a separação ao dividir o software em camadas.
• Tem pelo menos uma camada para as regras de negócio e uma camada para a interface com o usuário.

Projetos de software desenvolvidos seguindo a arquitetura limpa costumam ter as seguintes características:

• Independência de Frameworks: A arquitetura não depende da existência de nenhuma ferramenta externa a linguagem, como frameworks e bibliotecas, isso permite que você as use como tecnologias anexas ao projeto, ao invés de limitar o seu projeto as restrições de cada uma delas.

• Testabilidade: Onde as regras de negocio do projeto podem ser testadas sem a necessidade de interface, banco de dados, servidor web ou qualquer outro elemento externo.

• Independência da Interface do Usuário: A interface do usuário deve ser facilmente substituída, sem impactar o restante do sistema, por exemplo, uma interface web pode ser substituída por uma interface de console sem alterar as regras do negocio. Regras de negocio jamais devem ser implementadas na interface do usuário.

• Independência de Banco de Dados: Assim como a interface do usuário, você deve ser capaz de trocar de banco de dados, por exemplo, de MySQL para Postgres com zero impacto nas regras pois elas não estão ligadas as diretamente as convenções e regras de um determinado banco de dados.

• Independência de qualquer elemento externo: As regras de negocio não devem saber absolutamente nada sobre as interfaces com o mundo externo.

Fonte: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Camadas concêntricas:

• Entities: Representam as tabelas do banco de dados dentro do projeto, aqui definimos as propriedades, tipos e acessos (getters e setters).

• Use Cases: Representam as regras de negócio da aplicação, é responsável pela comunicação com as entidades, toda e qualquer informação deve passar por ela obrigatoriamente, em muitos casos a camada Service é usada como papel na camada de casos de uso.

• Adapters ou Ports and Adapters: É feita a tradução para a comunicação com os elementos externos, nessa camada costumamos ter os controllers, presenters e repositories usados como adaptadores.

• Frameworks and Drivers: É nessa camada que temos os elementos que precisam de alguma forma se comunicar com o núcleo do nosso projeto, banco de dados, frameworks, dispositivos e interfaces externas.

Podemos criar mais camadas se necessário, para separar ainda mais as responsabilidades, porém, sem interferir na regra da dependência.

Regra da Dependencia - As dependências devem sempre apontar para o nível mais alto da aplicação, ou seja, sempre para as camadas mais internas, as entities por exemplo, não podem saber nada do que ocorre na camada de use cases, que por sua vez, não deve saber nada da camada de adapters. O que queremos dizer é que qualquer alteração, por exemplo, na camada de controllers não deve impactar em absolutamente nada em que esteja na camada de casos de uso e nem na camada de entities.