Clean Architecture

"Clean Architecture" é um livro escrito por Robert C. Martin, também conhecido como Uncle Bob, no qual ele explica como projetar e desenvolver sistemas de software fáceis de manter, testar e modificar. Aqui estão os principais pontos do livro:

O objetivo da arquitetura de software é minimizar os recursos humanos necessários para construir e manter o sistema necessário.
A arquitetura limpa não é um conjunto de regras, mas sim um conjunto de princípios e práticas que guiam o design e desenvolvimento de sistemas de software.
A arquitetura de um sistema deve ser independente dos detalhes de implementação, como frameworks, bancos de dados ou interfaces de usuário.
A arquitetura de um sistema deve ser baseada em casos de uso e requisitos, não em restrições técnicas ou preferências.
A arquitetura de um sistema deve ser dividida em camadas, cada uma com suas próprias responsabilidades e dependências.
As camadas do sistema devem ser organizadas de maneira que permita a fácil teste e modificação dos componentes do sistema.
As dependências entre as camadas devem ser direcionadas para as abstrações estáveis do sistema, que devem ser definidas por interfaces e contratos.
A arquitetura de um sistema deve ser projetada para suportar a evolução do sistema, sem quebrar a funcionalidade existente ou introduzir regressões.
O uso de padrões de design e princípios SOLID pode ajudar a alcançar uma arquitetura limpa.

Sem dependências externas

Independente de Estruturas. A arquitetura não depende da existência de alguma biblioteca de software carregado de recursos. Isso permite que você use essas estruturas como ferramentas, em vez de ter que enfiar seu sistema em suas restrições limitadas.
Testável. As regras de negócios podem ser testadas sem a interface do usuário, banco de dados, servidor Web ou qualquer outro elemento externo.
Independente da interface do usuário. A interface do usuário pode ser alterada facilmente, sem alterar o restante do sistema. Uma interface do usuário da Web pode ser substituída por uma interface do usuário do console, por exemplo, sem alterar as regras de negócios.
Independente de Banco de Dados. Você pode trocar Oracle ou SQL Server por Mongo, BigTable, CouchDB ou qualquer outra coisa. Suas regras de negócios não estão vinculadas ao banco de dados.
Independente de qualquer agência externa. Na verdade, suas regras de negócios simplesmente não sabem nada sobre o mundo exterior.

The Clean Architecture

Os círculos concêntricos representam diferentes áreas de software. Em geral, quanto mais você avança, mais alto o nível do software se torna. Os círculos externos são mecanismos. Os círculos internos são políticas.
À medida que você avança, o nível de abstração aumenta. O círculo mais externo é o detalhe concreto de baixo nível. À medida que você avança, o software se torna mais abstrato e encapsula políticas de nível superior. O círculo mais interno é o mais geral.

Layers

Camadas referem para uma separação lógica de preocupações. Você está organizando e dividindo seu código em várias camadas, de acordo com as responsabilidades, define protocolos de comunicação entre as camadas. Como resultado, você possui componentes separados que podem ser trocados por outra implementação sem afetar um sistema inteiro.

Regra de Dependência

Essa regra diz que as dependências do código-fonte só podem apontar para dentro. Nada em um círculo interno pode saber qualquer coisa sobre algo em um círculo externo. Em particular, o nome de algo declarado em um círculo externo não deve ser mencionado pelo código em um círculo interno. Isso inclui, funções, classes. variáveis ou qualquer outra entidade de software nomeada.

Da mesma forma, os formatos de dados usados em um círculo externo não devem ser usados por um círculo interno, especialmente se esses formatos forem gerados por uma estrutura em um círculo externo. Não queremos que nada em um círculo externo afete os círculos internos.

Uma coisa de dentro não pode depende de uma coisa de fora.
Uma coisa de fora depende da camada mais próxima de dentro.

Entidades

As entidades encapsulam as regras de negócios de toda a empresa ou aplicativo*.* Uma entidade pode ser um objeto com métodos, ou pode ser um conjunto de estruturas de dados e funções. Não importa, desde que as entidades possam ser reusadas.

Eles são os menos propensos a mudar quando algo externo muda. Por exemplo, você não esperaria que esses objetos fossem afetados por uma alteração na navegação de página ou segurança. Nenhuma mudança operacional em qualquer aplicativo em particular deve afetar a camada de entidade.

Use-cases

O software nesta camada contém regras de negócios específicas do aplicativo. Ele encapsula e implementa todos os casos de uso do sistema. Esses casos de uso orquestram o fluxo de dados de e para as entidades e direcionam essas entidades a usar suas regras de negócios em toda a empresa para atingir as metas do caso de uso.

Não esperamos que mudanças nesta camada afetem as entidades. Também não esperamos que essa camada seja afetada por alterações nas externalidades, como o banco de dados, a interface do usuário ou qualquer uma das estruturas comuns. Esta camada está isolada de tais preocupações.

No entanto, esperamos que as alterações na operação do aplicativo afetem os casos de uso e, portanto, o software nessa camada. Se os detalhes de um caso de uso mudarem, algum código nessa camada certamente será afetado.

Interface Adapters

O software nesta camada é um conjunto de adaptadores que convertem dados do formato mais conveniente para os casos de uso e entidades, para o formato mais conveniente para alguma agência externa, como o Banco de Dados ou a Web. É essa camada, por exemplo, que conterá totalmente a arquitetura MVC de uma GUI. Os Apresentadores, Visualizações e Controladores pertencem aqui. Os modelos provavelmente são apenas estruturas de dados que são passadas dos controladores para os casos de uso e depois retornam dos casos de uso para os apresentadores e visualizações.

Da mesma forma, os dados são convertidos, nesta camada, da forma mais conveniente para entidades e casos de uso, para a forma mais conveniente para qualquer estrutura de persistência que esteja sendo usada. ou seja, o banco de dados. Nenhum código dentro deste círculo deve saber nada sobre o banco de dados. Se o banco de dados for um banco de dados SQL, todo o SQL deve ser restrito a essa camada e, em particular, às partes dessa camada que têm a ver com o banco de dados.

Também nesta camada está qualquer outro adaptador necessário para converter dados de algum formulário externo, como um serviço externo, para o formulário interno usado pelos casos de uso e entidades.

Frameworks and Drivers

A camada mais externa é geralmente composta de frameworks e ferramentas como o Banco de Dados, o Web Framework, etc. Geralmente você não escreve muito código nesta camada além do código de cola que se comunica com o próximo círculo interno.

Esta camada é onde todos os detalhes vão. A Web é um detalhe. O banco de dados é um detalhe. Nós mantemos essas coisas do lado de fora, onde elas podem causar pouco dano.

Inversão de controle. A regra da dependência

Um dos conceitos mais importantes e onipresentes usados quase em todas as estruturas é Inversão de controle. As dependências do código-fonte podem apenas apontar para dentro. Nada em um círculo interno pode saber alguma coisa sobre algo em um círculo externo. Em particular, o nome de algo declarado em um círculo externo não deve ser mencionado pelo código em um círculo interno. Isso inclui funções, classes. variáveis ou qualquer outra entidade de software nomeada.

Advantages of the Clean Architecture

Modularize codebase (SOLID & Clean)
Encapsulate components
Testability
Maintainability
Extensibility
Decoupling
Reusability
Scalability
Separation of Concerns
Practices to consider:
- Domain-Driven Design
- Event-Driven Architecture
- Publish-Subscribe pattern
- Microservices Architecture

References

Usecases 1.bff