Introdução Os desenvolvedores front-end geralmente enfrentam problemas relacionados à arquitetura do aplicativo. Requer o uso de uma arquitetura que possa ser facilmente dimensionada e fornecer baixo acoplamento e alta coesão entre os módulos do aplicativo. Este artigo discute a arquitetura Feature-Sliced Design, pois, na minha opinião, é a melhor entre as opções disponíveis. Também explora a ideia do FSD e os problemas que esta metodologia arquitetônica resolve. Compararemos o FSD com arquiteturas clássicas e modulares e examinaremos seus prós e contras. Em primeiro lugar, vamos distinguir três conceitos: camada, fatia e segmento. Camadas As camadas são diretórios de nível superior e o primeiro nível de decomposição do aplicativo. São limitadas em número – máximo de 7 camadas – e padronizadas, embora algumas delas sejam opcionais. Atualmente, distinguem-se as seguintes camadas: Cada camada tem sua própria zona de responsabilidade e é voltada para os negócios. Vamos considerar cada camada separadamente. app: é aqui que a lógica do aplicativo é inicializada. Provedores, roteadores, estilos globais, declarações de tipo global, etc. são definidos aqui. Ele serve como ponto de entrada para o aplicativo. processos: esta camada lida com processos que abrangem várias páginas, como registro em várias etapas. Esta camada é considerada obsoleta, mas ainda pode ser encontrada ocasionalmente. É uma camada opcional. páginas: esta camada inclui as páginas do aplicativo. widgets: são componentes de UI independentes usados nas páginas. recursos: esta camada lida com cenários de usuário e funcionalidades que agregam valor ao negócio. Por exemplo, curtir, escrever comentários, avaliar produtos, etc. É uma camada opcional. entidades: esta camada representa entidades comerciais. Essas entidades podem incluir usuários, avaliações, comentários, etc. É uma camada opcional. compartilhado: esta camada contém componentes e utilitários reutilizáveis que não estão vinculados a uma lógica de negócios específica. Inclui um kit de UI, configuração do Axios, configuração do aplicativo, auxiliares que não estão vinculados à lógica de negócios, etc. Essas camadas ajudam a organizar a base de código e promovem uma arquitetura modular, sustentável e escalável. Uma das principais características do Feature-Sliced Design é sua estrutura hierárquica. Nesta estrutura, as entidades não podem usar funcionalidades de recursos porque os recursos estão em posições superiores na hierarquia. Da mesma forma, os recursos não podem usar componentes de widgets ou processos, pois as camadas acima só podem utilizar as camadas abaixo. Isso é feito para manter um fluxo linear direcionado apenas em uma direção. Quanto mais baixa uma camada estiver posicionada na hierarquia, mais arriscado será fazer alterações nela, pois é provável que ela seja usada em mais lugares no código. Por exemplo, o kit de UI na camada compartilhada é usado nos recursos, widgets e até mesmo nas camadas de página. Fatias Em cada uma das camadas, existem subdiretórios – fatias – o segundo nível de decomposição do aplicativo. Em fatias, a conexão não é com coisas abstratas, mas com entidades empresariais específicas. O principal objetivo das fatias é agrupar o código por seu valor. Os nomes das fatias não são padronizados, pois são determinados diretamente pela área de negócio do projeto. Por exemplo, em uma galeria de fotos, pode haver seções como foto, álbum e galeria. Uma rede social exigiria fatias como postagens, usuários e feeds de notícias. Fragmentos intimamente relacionados podem ser agrupados estruturalmente em um diretório, mas devem seguir as mesmas regras de isolamento que outras fatias - não deve haver acesso compartilhado ao código neste diretório. Segmentos Cada fatia consiste em segmentos. Os segmentos ajudam a dividir o código dentro de uma fatia com base em sua finalidade. Dependendo dos acordos da equipe, os segmentos podem mudar em composição e nomenclatura. Os seguintes segmentos são mais comumente usados: api - solicitações de servidor necessárias. UI - componentes de UI da fatia. modelo - Lógica de negócios, ou seja, interação com o estado. Por exemplo, ações e seletores. lib - funcionalidade auxiliar usada na fatia. config - configuração necessária do slice, mas o segmento de configuração raramente é encontrado. consts - constantes necessárias. API pública Cada fatia e segmento possui uma API pública. A API Pública é representada por um arquivo index.js ou index.ts, que permite extrair apenas a funcionalidade necessária da fatia ou segmento para o exterior e isolar funcionalidades desnecessárias. O arquivo de índice serve como ponto de entrada. Regras para a API pública: As fatias e os segmentos do aplicativo usam apenas a funcionalidade e os componentes da fatia definidos no arquivo de índice da API Pública. A parte interna da fatia ou segmento que não está definida na API Pública é considerada isolada e aberta apenas para acesso dentro da própria fatia ou segmento. A API Pública simplifica o trabalho com importação e exportação, portanto, ao fazer alterações no aplicativo, não há necessidade de alterar as importações em todo o código. Aprofundando-se na arquitetura Abstração e lógica de negócios Quanto mais alta a camada, mais ela está vinculada ao nó de negócios específico e mais lógica de negócios contém. Quanto mais baixa a camada, mais abstrações, reutilização e falta de autonomia na camada. Como o FSD resolve o problema? Uma das tarefas do Feature-Sliced Design é obter acoplamento fraco e alta coesão. É importante entender como o FSD alcança esse resultado. Na OOP, esses problemas há muito são resolvidos por meio de conceitos como , , e . Esses conceitos garantem isolamento, reutilização e versatilidade do código, onde resultados diferentes são obtidos dependendo de como um componente ou funcionalidade é utilizado. polimorfismo encapsulamento herança abstração O Feature-Sliced Design ajuda a aplicar esses princípios no frontend. e são alcançados por meio de camadas. Como as camadas inferiores são abstratas, elas podem ser reutilizadas em camadas superiores e, dependendo das condições, um componente ou funcionalidade pode funcionar de maneira diferente com base nos parâmetros ou adereços especificados. Abstração polimorfismo é conseguido através da API Pública, que isola o que não é necessário do exterior em fatias e segmentos. O acesso aos segmentos internos de uma fatia é restrito e a API Pública é a única maneira de acessar funcionalidades e componentes de uma fatia ou segmento. O encapsulamento também é obtida por meio de camadas, pois as camadas superiores podem reutilizar as camadas inferiores. A herança Comparação com a arquitetura clássica Acredito que você já se deparou com arquitetura clássica muitas vezes. A maioria dos autores utiliza-o em artigos educacionais e vídeos do YouTube devido à sua simplicidade. Não existe um padrão específico para arquitetura clássica. No entanto, muitas vezes você pode ver o seguinte formato: A arquitetura clássica tem desvantagens visíveis. A maior delas é que o projeto se torna difícil de manter devido às conexões implícitas entre os componentes e à confusão de módulos. As desvantagens da arquitetura clássica tornam-se mais aparentes com o tempo. Quanto mais o projeto evolui, mais a arquitetura do aplicativo se torna uma bagunça difícil de desvendar. A arquitetura clássica é adequada para pequenos projetos sem manutenção contínua ou projetos de estimação. O Feature-Sliced Design, graças aos seus conceitos e padrões, evita os problemas da arquitetura clássica. No entanto, o nível de compreensão e habilidades dos desenvolvedores que trabalham com FSD deve ser maior do que quando trabalham com arquitetura clássica. Normalmente, os desenvolvedores com menos de 2 anos de experiência nunca ouviram falar de FSD. No entanto, ao trabalhar com Feature-Sliced Design, os problemas precisam ser resolvidos “agora” e não “mais tarde”. Problemas no código e desvios dos conceitos tornam-se imediatamente aparentes Comparação com arquitetura modular simples A arquitetura modular simples tem várias desvantagens: Às vezes não está claro onde colocar funcionalidade em módulos ou componentes. Dificuldades em utilizar módulos dentro de outro módulo. Problemas com o armazenamento de entidades comerciais. Dependências implícitas em funções globais, levando a uma estrutura emaranhada. Parece que em qualquer projeto complexo ou moderadamente complexo, o Feature-Sliced Design deve ser preferido à arquitetura modular simples. O FSD resolve muitos problemas arquitetônicos fundamentais e tem poucas desvantagens. Em termos de simplicidade e velocidade de desenvolvimento, uma arquitetura modular simples pode ter uma vantagem sobre o FSD. Se for necessário um MVP ou um projeto de curta duração estiver sendo desenvolvido, uma arquitetura modular simples pode ser mais adequada que o FSD. Mas, em qualquer outro caso, um design com fatias de recursos parece preferível. O potencial do design fatiado por recursos FSD é uma metodologia arquitetônica jovem. No entanto, já está sendo utilizado por muitos bancos, fintech, B2B, empresas de comércio eletrônico e outras. Aqui está um link para o problema do GitHub com uma lista de empresas: . GitHub Issue O repositório GitHub com a documentação oficial do FSD tinha mais de 1,1 mil estrelas no momento da publicação deste artigo. A documentação está sendo ativamente expandida, e a equipe de desenvolvimento do FSD e a comunidade no Telegram e Discord estão disponíveis 24 horas por dia, 7 dias por semana, para ajudar as pessoas com questões relacionadas à arquitetura. O potencial desta arquitetura é altamente valorizado e seu uso é amplamente difundido entre grandes empresas em todo o mundo. Com a adoção adequada, o FSD tem potencial para se tornar a solução arquitetônica dominante na área de desenvolvimento front-end. Vantagens e desvantagens da arquitetura Vantagens Os componentes da arquitetura podem ser facilmente substituídos, adicionados ou removidos Padronização da arquitetura Escalabilidade A metodologia é independente da pilha de desenvolvimento. Conexões controladas e explícitas entre módulos sem efeitos colaterais inesperados. Metodologia arquitetônica voltada para negócios. Desvantagens Uma barreira de entrada mais elevada em comparação com muitas outras soluções arquitetónicas. Requer consciência, cultura de equipe e aderência aos conceitos. Desafios e questões precisam ser abordados imediatamente, e não mais tarde. Problemas de código e desvios de conceitos são imediatamente visíveis. No entanto, isso também pode ser visto como uma vantagem. Conclusão Feature-Sliced Design é uma descoberta interessante e valiosa que os desenvolvedores front-end devem conhecer e ser capazes de usar. O FSD pode fornecer às equipes uma arquitetura e cultura de desenvolvimento flexível, padronizada e escalonável. Porém, utilizar os aspectos positivos da metodologia requer conhecimento, consciência e disciplina da equipe. O FSD se destaca entre outras arquiteturas devido à sua clara orientação de negócios, definição de entidade, composição funcional e composição de componentes da aplicação. Você também pode explorar de forma independente exemplos de uso de FSD em projetos e a documentação oficial do Feature-Sliced Design: Documentação Oficial Exemplo. Cliente GitHub Exemplo. Loja de tênis e calçados Nike Exemplo. Sudoku Este post pode ser longo, mas espero que você tenha aprendido algo novo. Agradeço que você tenha terminado de ler esta postagem. Se você tiver alguma opinião ou dúvida, fique à vontade para deixar um comentário! Também publicado aqui
