Criado por Robert C. Martin em seu livro Arquitetura Limpa: O guia do artesão para estrutura e design de software, este modelo de arquitetura visa ser usado no design de codificação afim de facilitar o desenvolvimento de códigos, permitir boa manutenção e menos dependências.

Esta arquitetura foi derivada de outras arquiteturas já existentes, como a Arquitetura em Cebola e a Arquitetura Hexagonal que compartilham de ideias similares com a arquitetura limpa.

Vantagens

A seguir algumas das vantagens destacadas por Robert C. Martin ao usar uma arquitetura em camadas:

• Independente de Frameworks: Os frameworks devem ser vistos como ferramentas e sua arquitetura não pode se basear em um específico e se limitar à suas especificidades, fazendo assim com que seja simples uma troca de framework caso seja necessário;
• Testabilidade: A lógica de negócio pode ser testada sem a interface de usuário, banco de dados, servidor web, ou qualquer outro elemento externo;
• Independente de interface de usuário: A interface de usuário pode ser mudada facilmente sem precisar mudar o resto do sistema. Uma interface web, por exemplo, poderia ser substituída por uma interface de linha de comando sem mudar as regras de negócio;
• Independente do Banco de Dados: O banco de dados pode ser trocado facilmente por qualquer outro banco de dados. As regras de negócios não estão amarradas ao banco de dados;
• Independente de qualquer agente externo: A lógica de negócio não deve ter conhecimento nenhum de qualquer agente externo.

Camadas

Como foi visto a Arquitetura Limpa se preocupa muito com o SoC (Separation of Concerns), princípio de engenharia de software que visa separar as preocupações, ou seja, modularizar um sistema de forma que cada parte seja responsável por resolver apenas um problema. A Figura abaixo mostra como deve ser feita a divisão do sistema em camadas.

Como pode ser visto a arquitetura é dividida nas seguintes camadas:

• Entities (Entidades): As entidades encapsulam as regras de negócios do sistema, contratos de serviços e outras funções referentes a manipulação de dados do sistema. Elas são as menos prováveis de haver mudanças quando algo externo é modificado;
• Casos de Uso (Use cases): Nessa parte estão representadas ações dentro do sistema aqui são encapsulados e implementados todos os casos de uso do sistema. Estes casos de uso orquestram fluxos de dados para as regras de negócio, validação e posteriormente persistências. Uma modificação nesta camada não deve influenciar modificações na camada de entidades e uma modificação externa não deve resultar em modificações nesta camada;
• Adaptadores de Interface (Interface Adapters): Estava camada é responsável por prover código que fará conversões do formato de dados utilizado pelas entidades e casos de usos para o formato mais conveniente para algum agente externo como banco de dados ou interfaces web.
• Frameworks e Drivers (Frameworks & Drivers): Ferramenta mais externa que geralmente é composta por bancos de dados, frameworks e etc. Aqui é onde o código Flutter será alocado.

Como pode ser visto essa divisão ajuda na hora que for preciso migrar para outra tecnologia (Bancos de dados ou frameworks, por exemplo), facilita a criação de testes e também a parte de manutenção do sistema, já que suas responsabilidade estão bem definidas.

Conclusão

Se você ou sua equipe estão desenvolvendo um sistema que tende a escalar, essa arquitetura, apesar de ser muito trabalhosa de implementar no início, tende-se a se pagar no futuro reduzindo tempo de possíveis alterações e/ou migrações.