Nossa Saga com Arquitetura Limpa — parte 1

Diagrama da Arquitetura Limpa, retirado do blog de Robert C. Martin

Começando com a nossa saga de arquitetura, à partir desse post, vamos falar um pouco sobre algumas decisões que tomamos aqui na Estoca e como elas impactam diretamente na construção e evolução da nossa plataforma!

Porém, antes disso, precisamos esclarecer alguns conceitos…

Ao longo do tempo, diversos conceitos e arquiteturas de software foram criadas e desenvolvidas para solucionar um princípio de design conhecido como SOC (em inglês, Separation of Concerns).

Entendendo um pouco mais, os Concerns são diferentes aspectos que um determinado software pode nos fornecer.

Já o SOC, é um príncipio de design que gerencia a complexidade desses aspectos, quebrando o software para que cada parte dele seja responsável por um Concern, para que dessa forma possamos minimizar ao máximo a sobreposição entre esses diferentes aspectos.

Saindo um pouco da teoria, pense da seguinte forma, se você é desenvolvedor ou engenheiro de software já deve ter trabalhado em algum projeto onde:

1. parte (ou boa parte, rsrsrs 😅) das regras de negócio estavam definidas em interfaces de usuário impedindo o seu reuso?
2. existia um alto acoplamento entre as regras de negócio e uma camada de persistência dos dados?

Arquitetura Limpa (em inglês, Clean Archictecture) é arquitetura de software (uma abordagem ou padrão de desenvolvimento) voltada para organização do código e das dependências entre os projetos que contemplam uma determinada solução, favorecendo a sua reusabilidade e independência de tecnologia.

Não confunda, a Arquitetura Limpa não é:

- Hexagonal Archictecture
- Onion Architecture

Porém, todas elas são arquiteturas centradas no domínio (em inglês, domain centric) e visam aplicar o mesmo prínpicio de design (o nosso conhecido SOC)!

Dito tudo isso, é importante citar o que as arquiteturas centradas no domíno vão nos trazer de benefícios:

• Independência de Estruturas
  A arquitetura não depende da existência de alguma framework de software. Isso permite que você use essas estruturas como ferramentas, em vez de ter que se submeter a restrições limitidas que elas podem criar
• Independência da Interface do Usuário
  A interface do usuário pode ser alterada facilmente, sem alterar o restante do projeto. Ou seja, uma determinada interface do usuário na Web pode ser substituída por uma interface do usuário de console, por exemplo, sem alterar as regras de negócio
• Independência de Banco de Dados
  Você pode trocar PostgreSQL, SQL Server ou Oracle para MongoDB ou qualquer outro similar, mas as suas regras de negócio não estarão vinculadas ao seu banco de dados ou a um determinado repositório
• Independência de Qualquer “Agente” Externo
  Na verdade, as suas regras de negócios simplesmente não sabem nada sobre o mundo exterior. O diagrama no início deste post é uma clara tentativa de integrar todas essas arquiteturas em uma única ideia acionável
• Testabilidade
  As regras de negócios podem ser testadas sem a interface do usuário, banco de dados, serviço Web, serviço de console ou qualquer outro elemento que componha o seu projeto

Considerando tudo isso que já citamos, pense que:

1. todos os seus modelos, entidades e regras de negócio tem que estar no projeto de domínio
2. todas as dependências existentes devem fluir para o projeto de domínio, fazendo com que ele fique livre
3. sempre que for possível, os demais projetos devem definir interfaces e os projetos que consumirem devem implementar os seus métodos

Mas também pense que nem sempre é o melhor caminho seguir a aplicação de uma arquitetura como essa, considerando que:

• O seu projeto terá maior complexidade
• O seu projeto pode ter um escopo reduzido ou até mesmo tempo determinado (não evolutivo)
• O time que vai trabalhar nesse projeto deve estar preparado para isso, conhecendo os conceitos e sabendo como aplicá-los
• Os custos das suas cargas de trabalho (workloads) podem ser elevados dependendo das escolhas que fizerem

Lembrando que teremos novos posts com a continuação dessa saga! 👀

Por fim, deixo uma ótima frase para você se lembrar no dia a dia:

“The only way to go fast, is to go well.”
— Robert C. Martin

Esperamos que essa publicação te ajude de alguma forma e até a próxima! 🚀

Referências:

• Diagrama de Arquitetura Limpa — https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg
• “Clean Architecture: A Craftsman’s Guide to Software Structure and Design”, de Robert C. Martin
• “Clean Code: A Handbook of Agile Software Craftsmanship”, de Robert C. Martin
• “The Clean Code Blog” (https://blog.cleancoder.com/), com publicações de Robert C. Martin