O código neste projeto é organizado como um monolito de arquitetura limpa, com os seguintes componentes conceituais típicos:
- Adaptadores de API
- Lógica de negócios de aplicativo separado
- Objetos de domínio principais
- Gateways de infraestrutura
- IoC (Inversão de Controle)
A solução é sem estado e, portanto, não contém gateways para camadas de persistência. A solução não tem interface do usuário, portanto, não tem controladores ou apresentadores.
A composição do componente de software usa a classe GridwichConfigureServices para definir quais classes concretas estão disponíveis no contêiner de IoC para o Aplicativo Azure Functions.
Arquitetura
A solução Gridwich tem uma biblioteca Core.EventGrid, que contém:
- Os DTOs (objetos de transferência de dados de solicitação de domínio e resposta).
- Interfaces para todos os objetos de serviço ou lógica de negócios de aplicativo.
- As classes base que ajudam a alcançar a lógica ou as atividades comuns controladas pelo domínio.
- Log, capacidade de observação e definições de exceção para uso no aplicativo.
Para encapsular a Grade de Eventos do Azure como um agente de solicitação e resposta, a biblioteca tem:
- Um dispatcher de eventos que usa o IoC para identificar e expedir eventos aos ouvintes.
- Um editor de eventos para colocar respostas no tópico correto da Grade de Eventos.
O adaptador de solicitação da Grade de Eventos é um ponto de extremidade HTTP na forma de um Ponto de Extremidade HTTP do Azure Function. Um adaptador para converter solicitações da Web em matrizes da Grade de Eventos também está na mesma EventGridFunction.
O gateway de resposta da Grade de Eventos consiste em:
- A EventGridHandlerBase, que converte um DTO de resposta em um objeto
EventGridEvent. - O EventGridDispatcher, que coloca o evento da Grade de Eventos no URI do ponto de extremidade de tópico da Grade de Eventos de resposta correta usando a chave do tópico.
A solução separa os participantes da saga nas bibliotecas a seguir, que têm responsabilidades sobre a lógica de negócios de aplicativo específica do domínio. As bibliotecas contêm gateways de infraestrutura necessários e seus SDKs, que realizam as ações que a lógica de negócios exige.
- Gridwich.SagaParticipants.Analysis.MediaInfo
- Gridwich.SagaParticipants.Encode.CloudPort
- Gridwich.SagaParticipants.Encode.Flip
- Gridwich.SagaParticipants.Storage.AzureStorage
Para reutilização e centralização de código, o Gridwich consolida gateways de infraestrutura ou lógica de negócios que vários participantes usam nas seguintes bibliotecas compartilhadas:
Alternativa a microsserviços
Nada no espaço ou arquitetura do problema do Gridwich envia por push explicitamente a solução para um aplicativo monolítico ou vários microsserviços.
Você pode facilmente refatorar o aplicativo em microsserviços, cada um aplicativo de funções que hospeda um único participante da saga. Cada aplicativo de Função vincularia as bibliotecas de Grade de Eventos principal e principal. Cada um dos aplicativos teria uma vinculação ou usaria uma biblioteca comum para gateways de infraestrutura.
A vantagem dessa abordagem de microsserviços é a capacidade de dimensionar de forma diferente para cada tipo de solicitação. Se houvesse milhares de um tipo de solicitação por segundo, mas apenas centenas de outro tipo de solicitação por dia, a solução geral se beneficiaria de ter funções menores, fáceis de instanciar e rápidas de executar para as solicitações de alto volume.
A desvantagem dos microsserviços é que todos os modelos compartilhados exigem a distribuição sincronizada dos microsserviços ou a drenagem e a substituição do pool de solicitações se houver uma alteração de esquema de dados. Esse requisito complicaria o desenvolvimento futuro, a implantação contínua e as operações. Como o problema de negócios não demonstra a necessidade de microsserviços, a arquitetura do Gridwich usa uma abordagem de monolito limpa.
Próximas etapas
- O que são microsserviços?: explore a arquitetura de microsserviços.
- Introdução ao Azure Functions: saiba mais sobre Azure Functions.