Direto ao ponto: Arquitetura Limpa

--

Como parte do meu Programa de Desenvolvimento Individual (PDI), tenho me dedicado a estudar a teoria dos conhecimentos que adquiri ao longo da minha carreira como desenvolvedor Swift. Este artigo detalha os meus estudos com base no livro de arquitetura limpa.

Primeiras impressões

Ler este livro proporcionou uma compreensão fundamental do conceito de arquitetura e como organizar suas partes para construir um todo coeso. Embora o livro aborde outros tópicos relacionados à arquitetura de forma mais geral, ainda assim recomendo a leitura como parte essencial do desenvolvimento profissional.

Um conceito amplamente discutido e referenciado no livro é o de camadas. Durante a leitura, pude compreender que esse termo na verdade engloba dois outros conceitos: contexto e dependência. O contexto se refere a um grupo de objetos que possuem um propósito em comum, seja definir o domínio da aplicação ou integrar a interface de rede no projeto. A dependência, por sua vez, estabelece as regras que definem quais outros contextos podem ser considerados dependências para o contexto em questão.

Através deste livro, pude compreender por que o domínio (Domain) é sempre um elemento central quando se fala de arquitetura. Ele define a base essencial do projeto a partir da qual todas as outras implementações se derivam.

Portanto, a leitura deste livro está muito mais relacionada ao desenvolvimento técnico e à compreensão do que é uma arquitetura do que à simples implementação seguindo um tutorial específico. É por isso que não há um código pronto disponível na internet quando se trata de arquitetura limpa.

Arquitetura Limpa

A arquitetura limpa enfatiza a importância da independência do projeto em relação ao sistema, considerando as unidades do sistema, como a interface do usuário, a impressora, os pen drives, entre outros.

A proposta é criar uma estrutura altamente organizada, reduzindo as dependências entre as unidades do sistema e facilitando a adaptação do projeto ao longo do tempo. Essa abordagem evita influências indesejadas e promove uma arquitetura sólida e resistente a modernizações. Assim, a arquitetura limpa busca prevenir problemas decorrentes de arquiteturas fracas e mal planejadas.

Uma arquitetura sólida permite que novos desenvolvedores tenham uma curva de aprendizado acelerada, encontrando suporte por meio de documentações e colaboração com seus colegas. Por outro lado, uma arquitetura que mistura vários padrões de design devido a influências passageiras de desenvolvedores que não se adaptam ao projeto pode resultar em complicações ainda maiores.

No contexto do Swift, é frequente a utilização de grupos como Domain, App Data, Networking, Storage e Features. A flexibilidade na definição desses grupos é um ponto positivo ressaltado no livro, permitindo que cada projeto determine a quantidade de grupos necessários, sem regras rígidas. É importante destacar que, independentemente dos grupos escolhidos, o Domain sempre estará presente como uma parte essencial da arquitetura.

Uma parte crucial da definição de um grupo dentro da arquitetura é estabelecer quais design patterns serão utilizados, qual problema o grupo busca solucionar e qual unidade de sistema ele está integrando. A presença do primeiro e do segundo grupo é fundamental para construir uma arquitetura consistente, enquanto a existência do terceiro grupo é opcional, embora seja a razão de existir da maioria dos grupos.

O último passo consiste em estabelecer as interdependências entre os grupos, resultando na estrutura arquitetural em camadas. Por exemplo, o grupo Domain é uma dependência do grupo App Data, que por sua vez é uma dependência dos grupos Networking e Storage, enquanto o grupo Domain também é uma dependência das Features. Essa visualização pode parecer um tanto confusa para desenvolvedores iniciantes no assunto, especialmente ao considerar que SwiftUI e Storage estão no mesmo nível arquitetural que Networking e UIKit.

O objetivo é compreender o propósito do gráfico que descreve as dependências individuais de cada grupo. Por exemplo, o SwiftUI depende das Features, que por sua vez depende do Domain. O Storage depende do AppData, que depende do Domain. O Networking depende do AppData, que também depende do Domain. Essa é a maneira correta de interpretar o gráfico.

Nesse formato visual alternativo, estamos destacando apenas as unidades de sistemas em que a arquitetura está inserida. Ao remover a visualização dos grupos, podemos identificar que temos recursos como Rede, Armazenamento e Interface Gráfica do Usuário (GUI) com os quais a arquitetura se relaciona. A partir disso, podemos desmembrar cada unidade de sistema em grupos e estabelecer as camadas conforme discutido anteriormente neste artigo.

Considerações finais

Como desenvolvedor Swift, recomendo a leitura deste livro, não necessariamente em cada detalhe apresentado, mas principalmente nas partes que explicam a construção de uma arquitetura do zero. É importante ressaltar que a arquitetura limpa não está relacionada à modularização em Cocoapods ou SPM, mas sim à independência das diferentes partes do software.

Pessoalmente, já desenvolvi vários aplicativos explorando os conceitos de arquitetura limpa, mas utilizando a modularização para delimitar essa visão de forma mais precisa.

Agradeço por ter lido até aqui e espero que essas informações sejam úteis para você 😉.

Se quiser contribuir para que eu possa continuar produzindo mais conteúdos técnicos, sinta-se à vontade para me oferecer um café ☕️ através da plataforma Buy me a Coffee.

Seu apoio é fundamental para manter meu trabalho e contribuir com a comunidade de desenvolvimento.

--

--

Brenno de Moura 🏳️‍🌈

Software engineer with a passion for technology and a focus on declarative programming, experience in challenging projects and multidisciplinary teams