Identificação dos limites do microfrontend - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Identificação dos limites do microfrontend

Para melhorar a autonomia da equipe, os recursos de negócios fornecidos por um aplicativo podem ser decompostos em vários microfront-ends com dependências mínimas entre si.

Seguindo a metodologia DDD discutida anteriormente, as equipes podem dividir um domínio de aplicativo em subdomínios de negócios e contextos limitados. As equipes autônomas podem então possuir a funcionalidade de seus contextos limitados e fornecer esses contextos como microfront-ends. Para obter mais informações sobre separação de interesses, consulte o diagrama Serverless Land.

Um contexto limitado bem definido deve minimizar a sobreposição funcional e a necessidade de comunicação em tempo de execução entre contextos. A comunicação necessária pode ser implementada com métodos orientados a eventos. Isso não é diferente da arquitetura orientada a eventos para desenvolvimento de microsserviços.

Um aplicativo bem arquitetado também deve oferecer suporte à entrega de futuras extensões por novas equipes para fornecer uma experiência consistente aos clientes.

Como dividir um aplicativo monolítico em microfront-ends

A seção Visão geral incluiu um exemplo de identificação de contextos funcionais independentes em uma página da web. Vários padrões para dividir a funcionalidade na interface do usuário surgem.

Por exemplo, quando os domínios de negócios formam estágios de uma jornada do usuário, uma divisão vertical no frontend pode ser aplicada, na qual uma coleção de visualizações da jornada do usuário é fornecida como microfront-ends. O diagrama a seguir mostra uma divisão vertical, em que as etapas de catálogo, finalização de compra e fatura são fornecidas por equipes separadas como microfront-ends separados.

Cada microfrontend tem um cabeçalho, um catálogo, detalhes da assinatura e um rodapé.

Para algumas aplicações, a divisão vertical sozinha pode não ser suficiente. Por exemplo, algumas funcionalidades podem precisar ser fornecidas em várias exibições. Para esses aplicativos, você pode aplicar uma divisão mista. O diagrama a seguir mostra uma solução dividida mista na qual os micro-front-ends do Station Finder e do Route Explorer usam a funcionalidade de visualização de mapa.

O Team Discover do Station Finder e o Team Route do Route Explorer usam a visualização de mapa, de propriedade da Team Map.

Aplicativos do tipo portal ou painel geralmente reúnem recursos de front-end em uma única visualização. Nesses tipos de aplicativos, cada widget pode ser fornecido como um microfrontend, e o aplicativo de hospedagem define as restrições e interfaces que os microfront-ends devem implementar.

Essa abordagem fornece um mecanismo para que os microfront-ends lidem com questões como tamanho da janela de visualização, provedores de autenticação, definições de configuração e metadados. Esses tipos de aplicativos otimizam a extensibilidade. Novos recursos podem ser desenvolvidos por novas equipes para escalar os recursos do painel.

O diagrama a seguir mostra um aplicativo de painel desenvolvido por três equipes individuais que fazem parte do Team Dashboard.

Aplicativo atual de painel para várias equipes, com a possibilidade de novos recursos por equipes futuras.

No diagrama, a visão futura representa novos recursos desenvolvidos por novas equipes para escalar o Team Dashboard e os recursos do painel.

Os aplicativos de portal e painel geralmente compõem a funcionalidade usando uma divisão mista na interface do usuário. Os microfront-ends são configuráveis com configurações bem definidas, incluindo restrições de posição e tamanho.