Após compreender sobre os conceitos chaves da Arquitetura Limpa e alguns conceitos importantes que a rodeiam como SOLID e princípios dos componentes, é mais fácil de entender sobre a sua divisão em camadas e seus limites.

Um sistema pode ser definido por três componentes básicos: a UI, as regras de negócio e o banco de dados - sendo que em sistemas maiores existem muito mais componentes. Para explicar o conceito de camadas e limites será utilizado o exemplo feito por MARTIN (2017) que descreve sobre o jogo da década de 1970 chamado Hunt the Wumpus.

As regras do jogo são irrelevantes para esse exemplo, pois o foco será na implementação em si.

Considerando que é utilizada uma UI baseada em texto, faz-se necessário desacoplar as regras do jogo para que ele possa ter diferentes idiomas. As regras se comunicarão com a UI utilizando uma API, independente do idioma, e a UI que fará a tradução para o idioma solicitado. Dessa forma todos os componentes da UI poderão fazer uso das mesmas regras do jogo. Supondo que o estado do jogo é mantido em um armazenamento persistente, não é preciso que as regras do jogo conheçam os detalhes, logo será criada uma API para fazer a comunicação dessas regras com o componente de armazenamento de dados.

As regras do jogo também não devem saber sobre os diferentes tipos de armazenamento de dados, logo as dependências devem ser direcionadas corretamente seguindo a Regra da Dependência, como visto na figura da estrutura básica do jogo (fonte: MARTIN (2017)).

Após essa breve descrição e baseando-se nos conceitos da Arquitetura Limpa, imagina-se que a arquitetura limpa seria facilmente aplicada nesse exemplo. Entretanto, não estão claros todos os limites arquiteturais.

Nesse exemplo o idioma não é o único eixo de mudança da UI, pode ser variado também o mecanismo de comunicação, como por exemplo uma aplicação de chat, uma janela normal ou mensagens de texto. Existem inúmeras possibilidades de mudança, o que mostra que há um limite arquitetural definido por esses eixos de mudança. Portanto, faz-se necessária a criação de uma API para cruzar esse limite e isolar o idioma do mecanismo de comunicação.

A figura acima reflete a estrutura do jogo reformulada (fonte: MARTIN (2017)), os retângulos pontilhados são as APIs e o retângulo escrito "Game Rules" contém as regras do jogo. O componente das regras do jogo está posicionado no topo do diagrama, pois nele estão as políticas de mais alto nível. Essa organização divide o fluxo de dados, sendo o lado esquerdo para se comunicar com o usuário e o direito para persistência dos dados. À medida que os sistemas vão crescendo, a estrutura de componentes pode se dividir em diversos fluxos com diferentes hierarquias, o que deixa a arquitetura cada vez mais complexa.

MARTIN (2017), conclui esse assunto afirmando que o papel do arquiteto de software é avaliar os custos, determinar os limites arquiteturais e quais desses limites devem ser implementados por completo, quais devem ser implementados parcialmente e quais devem ser ignorados.

Conclusão

Esse exemplo simples tem a finalidade de mostrar que existem limites arquiteturais em todos os lugares, e que cabe aos arquitetos de software reconhecer as necessidades.

É preciso saber também que a implementação desses limites é algo caro, porém, ao mesmo tempo, se não implementados no início do desenvolvimento podem ter custos ainda maiores ao longo do tempo.

Martin reforça que essas decisões não são tomadas uma única vez, que é necessário observar a evolução do sistema, analisar onde os limites podem ser necessários e o que pode acontecer caso não tenham limites bem definidos. Reforça a importância de comparar os custos de implementação desses limites com o custo de ignorá-los, buscando sempre implementar os limites certos no ponto ideal onde o custo de implementar seja menor do que o de ignorar.

Referências

• MARTIN, Robert C. Clean Architecture: A Craftsman’s Guide to Software Structure and Design. 1st. ed. USA: Prentice Hall Press, 2017. ISBN 0134494164.