Fique por dentro – Concurso de TI! Clean Achitecture

A construção de software sustentável, escalável e de fácil manutenção é um desafio constante no desenvolvimento de sistemas. Para resolver esse problema, Robert C. Martin (também conhecido como Uncle Bob) propôs a Clean Architecture (Arquitetura Limpa), um modelo arquitetural que promove a separação de responsabilidades e a independência das regras de negócio em relação a detalhes de implementação, como frameworks, bancos de dados e interfaces gráficas.

Neste artigo, vamos explorar os princípios fundamentais da Clean Architecture, entender como suas camadas se organizam e analisar questões de concursos públicos que cobram esse conhecimento.

O que é Clean Architecture?

A Clean Architecture é um modelo que busca garantir que o código seja bem organizado, reutilizável e independente de tecnologias externas. Seu princípio central é a Regra da Dependência, que estabelece que as dependências devem sempre apontar para dentro, ou seja, os módulos internos não devem depender de módulos externos (como frameworks ou bancos de dados), mas sim o contrário.

A proposta central da arquitetura é permitir que a lógica de negócio permaneça protegida de mudanças tecnológicas. Isso significa que um sistema pode, por exemplo, mudar o banco de dados ou o framework web sem impactar sua regra de negócio principal.

Os Princípios Fundamentais da Clean Architecture

1. Independência da Interface do Usuário
   • A lógica de negócios deve funcionar independentemente da interface gráfica. Isso significa que a camada de apresentação pode ser substituída sem afetar o funcionamento interno do sistema.
2. Independência de Banco de Dados
   • O sistema não deve depender de um banco de dados específico. A arquitetura permite que o banco seja alterado sem grandes impactos no código principal.
3. Independência de Frameworks e Bibliotecas
   • Frameworks são considerados detalhes de implementação e não devem estar acoplados às regras de negócio do sistema. Isso facilita a migração entre tecnologias.
4. Regra da Dependência
   • As dependências devem sempre apontar para dentro, garantindo que as regras de negócio permaneçam intactas e sem acoplamento com camadas externas.

Camadas da Clean Architecture

A Clean Architecture é representada por círculos concêntricos, onde cada camada tem um propósito bem definido. As camadas mais internas contêm as regras mais importantes, enquanto as camadas externas lidam com detalhes de implementação.

1. Entidades (Entities)

• Contém as regras de negócio mais genéricas e essenciais, reutilizáveis em diferentes contextos.
• Exemplo: Classes que representam conceitos centrais do domínio, como Cliente ou Pedido.

2. Casos de Uso (Use Cases ou Application Layer)

• Define os fluxos de negócios específicos da aplicação.
• Essa camada orquestra os processos, garantindo que a regra de negócio seja executada corretamente.
• Exemplo: Um caso de uso “Cadastrar Cliente” pode coordenar a criação do cliente e a validação dos dados antes de persistir a informação.

3. Adaptadores (Interface Adapters)

• Camada intermediária responsável por conectar os casos de uso com o mundo externo.
• Inclui controladores, gateways e conversores de dados.
• Exemplo: Um controlador HTTP que recebe uma requisição da API e a transforma para um formato que o caso de uso entende.

4. Frameworks e Drivers (External Systems)

• Contém tudo que é externo ao sistema: bancos de dados, frameworks web, bibliotecas de terceiros, interfaces gráficas e APIs.
• Exemplo: Banco de dados PostgreSQL, um framework como Spring Boot ou Express.js.

Vantagens da Clean Architecture

1. Facilidade de Manutenção
   • Com camadas bem definidas, modificar o código se torna mais simples e seguro.
2. Maior Testabilidade
   • Como a lógica de negócios não está acoplada a tecnologias externas, os testes unitários podem ser feitos sem precisar de banco de dados ou interface gráfica.
3. Reutilização de Código
   • As regras de negócio podem ser reaproveitadas em diferentes contextos e aplicações.
4. Menor Acoplamento
   • A separação de responsabilidades evita que mudanças tecnológicas impactem a lógica do sistema.

Conclusão

A Clean Architecture é uma abordagem que visa criar sistemas mais organizados, escaláveis e independentes de tecnologias externas. Seu princípio central, a Regra da Dependência, garante que as regras de negócio não sejam afetadas por mudanças nos frameworks, bancos de dados ou interfaces de usuário.

Essa arquitetura é amplamente aplicada em projetos modernos de software e frequentemente cobrada em concursos públicos. Compreender seus princípios e camadas é essencial para quem deseja se destacar na área de desenvolvimento de sistemas.

Referências:

• Robert C. Martin. Arquitetura Limpa: o Guia do Artesão Para Estrutura e Design de Software
• Robert C. Martin. Agile Software Development: Principles, Patterns, and Practices

Vamos ver como esse assunto é cobrado nos concursos!

A Clean Architecture (ou arquitetura limpa), criada por Robert C. Martin, considera como objetivo 

1. na arquitetura de software, padronizar e organizar o código desenvolvido, favorecer a sua reusabilidade, assim como a dependência de tecnologia.
2. fornecer aos desenvolvedores uma maneira de organizar o código de forma que generalize a lógica de negócios, mantendo-o separado do mecanismo de entrega e dependente do agente externo. 
3. proporcionar independência de interface do usuário e independência de qualquer agente externo, com exceçãoo da dependência de banco de dados específico
4. na arquitetura de software, minimizar os recursos humanos necessários para construir e manter o sistema necessário.
5. configurar as dependências de cada camada sempre em direção a periferia, tendo o core totalmente protegido de qualquer interferência externa ou interna. 

Gabarito: D

Comentário:

A) Errada. A Clean Architecture organiza o código e favorece a reutilização, mas seu foco é eliminar a dependência de tecnologia, garantindo que o sistema não dependa de frameworks ou bancos de dados específicos.

B) Errada. Embora a arquitetura separe a lógica de negócios dos mecanismos externos, seu objetivo é garantir independência total de agentes externos, e não criar dependência.

C) Errada. A Clean Architecture não deve depender de um banco de dados específico. A lógica de negócios precisa ser desacoplada para permitir a substituição do banco sem impacto significativo no sistema.

D) Correta. A Clean Architecture visa reduzir a complexidade e facilitar a manutenção do software, minimizando o esforço humano necessário para modificações e correções, graças à separação de responsabilidades e modularidade.

E) Parcialmente correta. A alternativa descreve corretamente a Regra da Dependência, mas foca em um conceito específico. A alternativa D representa melhor o objetivo maior da Clean Architecture, que é facilitar a evolução do software e reduzir o esforço humano envolvido.

2) Ano: 2024 Banca: FGV Órgão: CVM Prova: FGV – 2024 – CVM – Analista CVM – Perfil 8 – TI / Sistemas e Desenvolvimento – Tarde

A analista Raquel foi designada para refatorar o código de um sistema à luz da Arquitetura Limpa. Raquel iniciou a tarefa assimilando os princípios de design utilizados pela arquitetura. A analista seguiu determinando a camada apropriada da Arquitetura Limpa para cada módulo do sistema. Logo após, Raquel revisou a implementação dos módulos A e B, que encapsulam regras de negócio específicas à aplicação. A analista removeu as referências diretas aos módulos A e B no código da camada interior adjacente, aplicando o princípio de design que garante a não violação da Regra da Dependência ao longo das camadas, durante o fluxo de controle.

Raquel removeu as referências diretas aos módulos A e B da camada de:

1. entidades, aplicando a segregação de interface;
2. entidades, aplicando a inversão de dependência;
3. casos de uso, aplicando a segregação de interface;
4. adaptadores, aplicando a segregação de interface;
5. adaptadores, aplicando a inversão de dependência.

Gabarito: B

Comentário:

A) Errada. A segregação de interface é um conceito relacionado ao princípio SOLID, não diretamente à Clean Architecture.

B) Correta. A camada de entidades contém as regras de negócio mais fundamentais. A inversão de dependência garante que essa camada não dependa diretamente de módulos externos, mas sim o contrário.

C) Errada. Casos de uso fazem parte da lógica de aplicação, mas a inversão de dependência se aplica mais fortemente às entidades.

D) Errada. Adaptadores são responsáveis por conectar o sistema ao mundo externo, mas não são o foco principal da inversão de dependência.

E) Errada. A inversão de dependência pode ser aplicada em diferentes camadas, mas as entidades são as mais críticas para manter essa separação.