Conceitos fundamentais

A arquitetura de microfront-end é fortemente inspirada em três conceitos arquitetônicos anteriores:

• O design orientado por domínio é o modelo mental para estruturar aplicativos complexos em domínios coerentes.

• Os sistemas distribuídos são uma abordagem para criar aplicativos como subsistemas fracamente acoplados que são desenvolvidos de forma independente e executados em sua própria infraestrutura dedicada.

• A computação em nuvem é uma abordagem para executar a infraestrutura de TI como serviços com um pay-as-you-go modelo.

Design orientado por domínio

O design orientado por domínio (DDD) é um paradigma desenvolvido por Eric Evans. Em seu livro de 2003, Domain-Driven Design: Tackling Complexity in the Heart of Software, Evans postula que o desenvolvimento de software deve ser orientado por questões comerciais e não técnicas. Evans propõe que os projetos de TI desenvolvam primeiro uma linguagem onipresente que ajude especialistas técnicos e de domínio a encontrar um entendimento compartilhado. Com base nessa linguagem, eles podem formular um modelo mutuamente compreendido da realidade empresarial.

Por mais óbvia que seja essa abordagem, muitos projetos de software sofrem com a desconexão entre os negócios e a TI. Essas desconexões geralmente causam mal-entendidos significativos, o que leva a excessos orçamentários, diminuição da qualidade ou falha do projeto.

Evans introduz vários outros termos importantes, um dos quais é o contexto limitado. Um contexto limitado é um segmento independente de um grande aplicativo de TI que contém a solução ou implementação para exatamente uma preocupação comercial. Um aplicativo grande consistirá em vários contextos limitados que são vagamente acoplados por meio de padrões de integração. Esses contextos limitados podem até ter seus próprios dialetos da linguagem onipresente. Por exemplo, um usuário no contexto de pagamento de um aplicativo pode ter aspectos diferentes de um usuário no contexto de entrega porque a noção de frete seria irrelevante durante o pagamento.

Evans não define o quão pequeno ou grande um contexto limitado deve ser. O tamanho é determinado pelo projeto de software e pode evoluir com o tempo. Bons indicadores dos limites de um contexto são o grau de coesão entre as entidades (objetos de domínio) e a lógica de negócios.

No contexto de microfrontends, o design orientado por domínio pode ser ilustrado pelo exemplo de uma página da web complexa, como uma página de reserva de voos.

Nesta página, os principais blocos de construção são um formulário de pesquisa, um painel de filtros e a lista de resultados. Para identificar os limites, você deve identificar contextos funcionais independentes. Além disso, considere aspectos não funcionais, como reutilização, desempenho e segurança. O indicador mais importante de que “coisas que pertencem umas às outras” são seus padrões de comunicação. Se alguns elementos em uma arquitetura precisam se comunicar com frequência e trocar informações complexas, eles provavelmente compartilham o mesmo contexto limitado.

Elementos individuais da interface do usuário, como botões, não são contextos limitados, porque não são funcionalmente independentes. Além disso, a página inteira não é adequada para um contexto limitado, pois pode ser dividida em contextos independentes menores. Uma abordagem razoável é tratar o formulário de pesquisa como um contexto limitado e tratar a lista de resultados como o segundo contexto limitado. Cada um desses dois contextos limitados agora pode ser implementado como um microfrontend separado.

Sistemas distribuídos

Para facilitar a manutenção e apoiar a capacidade de evolução, a maioria das soluções de TI não triviais são modulares. Nesse caso, modular significa que os sistemas de TI consistem em blocos de construção identificáveis que são desacoplados por meio de interfaces para obter a separação das preocupações.

Além de serem modulares, os sistemas distribuídos devem ser sistemas independentes por si só. Em um sistema meramente modular, cada módulo é idealmente encapsulado e expõe suas funções por meio de interfaces, mas não pode ser implantado de forma independente ou mesmo funcionar sozinho. Além disso, os módulos geralmente seguem o mesmo ciclo de vida de outros módulos que fazem parte do mesmo sistema. Os blocos de construção de um sistema distribuído, por outro lado, têm seus próprios ciclos de vida. Aplicando o paradigma de design orientado por domínio, cada componente básico aborda um domínio ou subdomínio comercial e vive em seu próprio contexto limitado.

Quando sistemas distribuídos interagem durante o tempo de construção, uma abordagem comum é desenvolver mecanismos para identificar problemas rapidamente. Por exemplo, você pode adotar linguagens digitadas e investir pesadamente em testes unitários. Várias equipes podem colaborar no desenvolvimento e na manutenção de módulos, geralmente distribuídos como bibliotecas para sistemas consumirem com ferramentas como npm, Apache Maven e pip. NuGet

Durante o tempo de execução, os sistemas distribuídos que interagem normalmente são de propriedade de equipes individuais. O consumo de dependências causa complexidade operacional devido ao tratamento de erros, ao balanceamento de desempenho e à segurança. Investimentos em testes de integração e observabilidade são fundamentais para reduzir riscos.

Atualmente, os exemplos mais populares de sistemas distribuídos são os microsserviços. Nas arquiteturas de microsserviços, os serviços de back-end são orientados por domínio (e não por questões técnicas, como interface de usuário ou autenticação) e de propriedade de equipes autônomas. Os microfront-ends compartilham os mesmos princípios, estendendo o escopo da solução ao frontend.

Computação em nuvem

A computação em nuvem é uma forma de comprar infraestrutura de TI como serviços com um pay-as-you-go modelo, em vez de construir seus próprios data centers e comprar hardware para operá-los localmente. A computação em nuvem oferece várias vantagens:

• Sua organização ganha agilidade comercial significativa ao ser capaz de experimentar novas tecnologias sem ter que assumir compromissos financeiros grandes e de longo prazo antecipadamente.

• Ao usar um provedor de nuvem como AWS, sua organização pode acessar um amplo portfólio de serviços altamente integráveis e de baixa manutenção (como gateways de API, bancos de dados, orquestração de contêineres e recursos de nuvem). O acesso a esses serviços libera sua equipe para se concentrar no trabalho que diferencia sua organização da concorrência.

• Quando sua organização estiver pronta para implantar uma solução globalmente, você poderá implantar a solução na infraestrutura de nuvem em todo o mundo.

A computação em nuvem oferece suporte a microfront-ends fornecendo uma infraestrutura altamente gerenciada. Isso facilita end-to-end a propriedade de equipes multifuncionais. Embora a equipe deva ter um forte conhecimento operacional, as tarefas manuais de provisionamento da infraestrutura, atualizações do sistema operacional e rede seriam uma distração.

Como os microfront-ends vivem em contextos limitados, as equipes podem escolher o serviço mais adequado para executá-los. Por exemplo, as equipes podem escolher entre funções de nuvem e contêineres para computação, e podem escolher entre diferentes tipos de bancos de dados SQL e NoSQL ou caches na memória. As equipes podem até mesmo criar seus microfront-ends em um kit de ferramentas altamente integrado AWS Amplify, como o, que vem com blocos de construção pré-configurados para infraestrutura sem servidor.