Principais pontos do livro Clean Architecture

Introdução

O meu último livro que li foi o “Clean Architecture: A Craftsman's Guide to Software Structure and Design” do escritor e desenvolvedor Robert Martin (chamado também de Uncle Bob). Junto a leitura eu estava acompanhando um curso de Arquitetura de Software do Rodrigo Manguinho. Então, muito do eu li acabei reconhecendo no treinamento e muito do que foi praticado no treinamento eu reconheci no livro.

Foi uma leitura bem gratificante e um tanto desafiante, até porque eu peguei a versão original do livro, em inglês. O objetivo era aprender noções de arquitetura de software e de quebra praticar um idioma que não é o meu nativo. Por esse motivo, deve ter algumas ideias que talvez eu tenha deixado passar, entretanto, pretendo reler esse livro futuramente mais vezes.

O que é uma arquitetura?

Uma arquitetura é uma mistura de duas coisas: estrutura e comportamento.

Como comparação a uma arquitetura de uma casa, há tanto a parte estrutural - onde cada cômodo está localizado, o tamanho do jardim, área de lazer, quantidade de vagas na garagem, etc. Como a parte que dita o comportamento: os disjuntores elétricos, quais os interruptores que controlam cada lâmpada, as torneiras e encanamentos, e assim por diante. Dessa forma, temos ideia total do projeto e como ele deve funcionar e estar estruturado.

Na arquitetura de software é semelhante. Ela organiza o projeto tanto na parte estrutural, de pastas, camadas e dependências, quanto comportamental, nas responsabilidades de cada um dos elementos de software (classes, funções, componentes, etc.).

Para que serve

Quando um software é organizado e desacoplado, é muito mais fácil moldá-lo para continuar atendendo seus requisitos, à medida que esses requisitos mudam com o tempo.

Por exemplo, um software de logística de uma transportadora que usa caminhões para fazer entregas. Por um acaso, a empresa se expande para transportar via fluvial. O software deve se moldar para atender aos novos requisitos, que podem incluir novas abordagens de cálculos de frete, tempo, disponibilidade de transportes, localidades, e uma lista gigante de novas features. Com uma boa arquitetura, essa tarefa se torna relativamente fácil. Sem ela, se torna um pesadelo.

Da mesma forma, se, por exemplo, o primeiro usa MongoDB para salvar seus dados e por algum problema se faz necessário trocar para PostgreSQL, com uma boa arquitetura isso pode ser feito sem grandes dores de cabeça. Seria tão fácil quanto escrever mais código ao invés de modificar o existente.

Sei que na teoria tudo parece muito bonito e, na prática, as coisas podem sair do controle independente de como um projeto está organizado — e, aliás, quem penso que sou para falar assim? —. Mas, um projeto bem organizado aumenta muito a capacidade dele se moldar para atender novas exigências.

Isso tudo parece ótimo, mas por que então todo mundo já não faz dessa forma? O autor explica que, para implementar uma boa arquitetura, precisamos gastar mais tempo com planejamento e, de certa forma, aumentar a complexidade do projeto. Gastar mais tempo para atingir o “mesmo objetivo” não é algo que os Product Owners irão algum dia desejar. Precisamos criar muito mais código inicial para atender poucas features e isso acaba não cabendo nos prazos — há quem chame de Sprint — delegados aos programadores. Apesar disso, é responsabilidade do time de programadores negociar e argumentar quanto a melhor abordagem para a conclusão do projeto.

Como funciona?

Há algumas regras importantes quanto ao Clean Architecture. A principal delas é o desacoplamento das regras de negócios dos “detalhes”. As regras de negócio são abstrações dos problemas reais que independem de qualquer framework, banco de dados ou qualquer outra coisa do gênero. Uma conta bancária, por exemplo, possui informações e comportamentos que não dependem de qualquer ferramenta relacionada a software. Fazer uma transferência entre as contas é um caso de uso que segue a mesma linha de raciocínio.

Por outro lado, onde essa conta bancária ficará armazenada é um detalhe. Se o projeto será acessado em caixas bancários, uma aplicação mobile, ou web, também é detalhe. Portanto, as suas regras de negócios não devem saber e nem depender de detalhes, mas sim o contrário.

Atente-se que, dessa forma, temos uma aplicação dividida em duas grandes camadas (por enquanto), regras de negócios, mais interna e detalhes, mais externa. As camadas mais internas não devem mudar por conta de uma mudança em camadas externas. As suas regras de negócios devem ser independentemente testáveis. Assim, o Princípio de Inversão de Dependência se torna muito importante para direcionar o sentido de dependência entre as camadas. Sempre dependa em direção à estabilidade, ou seja, para a camada mais interna.

Outro princípio muito importante é deixar o máximo de opções abertas por mais tempo possível. Não faça escolhas precoces. Utilize as suas abstrações para ir desenvolvendo e testando suas regras de negócio e quando você realmente precisar escolher entre um framework, ou um banco de dados, terá mais informações para fazer bem essa escolha.

As camadas do Clean Architecture

Enterprise Business Rules (Entities)

Camada amarela, mais interna. São regras de negócio genéricas, que independem de qualquer aplicação. Poderiam ser usadas em qualquer outra aplicação. Quando há uma mudança externa, essa é a última camada que geralmente deve sofrer alguma modificação.

Application Business Rules (Use cases)

Camada Vermelha. São também regras de negócio, porém relacionadas à aplicação específica. Ela deve saber apenas sobre a camada Entities. Entretanto, ela não “enxerga” as camadas referentes a bancos de dados e frameworks externos.

Interface Adapters

Camada que “traduz” os dados das camadas anteriores em algo mais conveniente para os “detalhes”, seja a web, frameworks ou database. Controladores e Presenters pertencem a esta camada.

Frameworks e Drivers

Camada onde todos os detalhes devem estar. O banco de dados, frameworks, UI, etc. É importante evitar escrever muito código aqui, por ser a camada mais instável, que pode mudar frequentemente.

Em suma

Devemos proteger o que é específico da aplicação e estável, do que é instável e externo. O livro Clean Architecture é muito interessante, tem vários outros assuntos que nem cheguei a citar aqui, como algumas experiências de trabalho que o Robert Martin teve, uma detalhada explicação sobre SOLID, componentes, formas de dividir um projeto, medir a instabilidade de uma entidade de software, etc. Recomendo que o leia por inteiro, pois são décadas de experiência do autor no assunto, condensados em uma linguagem simples.

Referência

Clean Coder Blog

Clean Architecture: A Craftsman's Guide to Software Structure and Design