Analisar uma aplicação e identificar os limites de decomposição

Concluído

Para mover a aplicação para uma arquitetura de microsserviços, a Fabrikam precisa de avaliar a aplicação atual e determinar o âmbito e o limite de cada microsserviço. Para essa avaliação, eles usarão a estrutura de design controlado por domínio (DDD). Vamos ver como aplica esta arquitetura à aplicação.

Nota

Este artigo não apresenta uma análise de domínios completa e abrangente. Mantivemos o exemplo breve deliberadamente para ilustrar os principais pontos. Para obter mais informações sobre DDD, consulte a seção "Saiba mais" no resumo no final deste módulo.

O que é a estruturação baseada em domínio?

DDD é uma abordagem ao design de sistemas originalmente introduzida por Erik Evans no livro de 2005 Domain-Driven Design: Tackling Complexity in the Heart of Software. Esta abordagem inclui três elementos principais:

• Ênfase no domínio principal e na lógica de domínio.
• Estruturar o design num modelo do domínio.
• Conduzir a colaboração iterativa entre as equipas técnicas e os parceiros de negócio para melhorar constantemente o sistema.

DDD fornece uma estrutura que pode levá-lo ao máximo do caminho para um conjunto de microsserviços bem projetados. Tem duas fases distintas, estratégica e tática. Na DDD estratégica, define a estrutura em grande escala do sistema. O DDD estratégico ajuda a garantir que a sua arquitetura permanece focada nas capacidades do negócio. O DDD tático fornece um conjunto de padrões de design que pode utilizar para criar o modelo de domínio. Estes padrões incluem entidades, agregações e serviços de domínio. Estes padrões táticos vão ajudá-lo a criar microsserviços associados e coesos.

Durante a fase estratégica da DDD, deverá mapear o domínio do negócio e definir os contextos vinculados dos modelos de domínio. O DDD tático é quando define os modelos de domínio com mais precisão. Os padrões táticos são aplicados num único contexto vinculado. Numa arquitetura de microsserviços, estamos interessados nos padrões de entidade e agregação. A aplicação destes padrões ajuda-nos a identificar limites naturais para os serviços na nossa aplicação. Como princípio geral, um microsserviço não deve ser menor do que uma agregação e não deve ser maior do que um contexto vinculado.

De modo geral, pode dividir este processo em quatro passos:

1. Analise o domínio de negócio para entender os requisitos funcionais da aplicação. A saída deste passo é uma descrição informal do domínio, que pode ser melhorada para um conjunto mais formal de modelos de domínio.
2. Defina os contextos vinculados do domínio. Cada contexto vinculado contém um modelo de domínio que representa um subdomínio específico da aplicação maior.
3. Dentro de um contexto vinculado, aplique padrões de DDD táticos para definir entidades, agregações e serviços de domínio.
4. Identifique os microsserviços na aplicação ao utilizar os resultados do passo anterior.

Vamos analisar mais de perto o que acontece em cada um destes passos.

Analisar o domínio de negócio

O DDD começa por modelar o domínio de negócio e criar um modelo de domínio. O modelo de domínio é um modelo abstrato do domínio de negócio. Mostra e organiza o conhecimento do domínio e fornece uma linguagem comum para programadores e especialistas em domínio.

Comece por mapear todas as funções de negócio e respetivas ligações. Esta análise é um esforço colaborativo que envolve especialistas de domínio, arquitetos de software e outras partes interessadas. Não precisa de utilizar nenhum formalismo específico. Esboce um diagrama ou desenhe-o num quadro branco.

Ao preencher o diagrama, pode começar a identificar subdomínios discretos. Que funções estão fortemente relacionadas? Que funções são fundamentais para o negócio e quais fornecem serviços auxiliares? O que é o gráfico de dependência? Durante esta fase inicial, não está preocupado com as tecnologias ou os detalhes de implementação. Dito isto, deve observar o local onde a aplicação terá de ser integrada com sistemas externos, como CRM, processamento de pagamentos ou sistemas de faturação.

Definir contextos vinculados

O modelo de domínio inclui representações de coisas reais no mundo, como utilizadores, drones e pacotes. No entanto, isso não significa que todas as partes do sistema tenham de utilizar as mesmas representações para as mesmas coisas.

Por exemplo, subsistemas que lidam com a reparação de drones e a análise preditiva precisam de representar muitas das características físicas dos drones. Estas características incluem o histórico de manutenção, a quilometragem, a idade, o número do modelo e detalhes de desempenho. Contudo, na altura de agendar uma entrega, não nos preocupamos com essas coisas. O subsistema de agendamento só precisa de saber se um drone está disponível e a hora estimada de chegada (ETA) para a recolha e entrega.

Se tentarmos criar um modelo único para ambos os subsistemas, é mais complexo do que precisamos. Também é mais difícil para o modelo evoluir ao longo do tempo, pois as alterações têm de satisfazer múltiplas equipas que trabalham em subsistemas separados. Geralmente, é melhor criar modelos separados que representem a mesma entidade do mundo real (neste caso, um drone) em dois contextos diferentes. Cada modelo contém apenas as funcionalidades e atributos que são relevantes no respetivo contexto específico.

É nesta abordagem que entra em jogo o conceito DDD de contextos limitados. Um contexto vinculado é simplesmente o limite num domínio em que um modelo de domínio específico se aplica. Ao observar o diagrama anterior, podemos agrupar a funcionalidade de acordo com a possibilidade de várias funções partilharem um único modelo de domínio.

Definir entidades, agregações e serviços

O DDD tático é quando define os modelos de domínio com mais precisão. Os padrões táticos são aplicados num único contexto vinculado. Numa arquitetura de microsserviços, estamos interessados nos padrões de entidade e agregação. A aplicação destes padrões ajuda-nos a identificar limites naturais para os serviços na nossa aplicação. Como princípio geral, um microsserviço não deve ser menor do que uma agregação e não deve ser maior do que um contexto vinculado.

Existem vários padrões de DDD tático a serem considerados:

• Entidades: uma entidade é um objeto com uma identidade exclusiva que persiste ao longo do tempo. Por exemplo, numa aplicação bancária, os clientes e as contas são entidades.
• Objetos de valor: um objeto de valor não tem identidade. Os valores dos seus atributos definem-no, e é imutável. Exemplos típicos de objetos de valor incluem cores, datas, horas e valores de moeda.
• Agregações: uma agregação define um limite de consistência em torno de uma ou mais entidades. A finalidade de uma agregação é modelar invariáveis transacionais. As coisas no mundo real têm redes complexas de relações. Os clientes criam pedidos, os pedidos contêm produtos, os produtos têm fornecedores e assim por diante. Se a aplicação modificar vários objetos relacionados, como garante a consistência? Como mantemos o controlo das invariáveis e as aplicamos?
• Serviços de domínio e aplicação: Na terminologia DDD, um serviço é um objeto que implementa alguma lógica sem conter qualquer estado. Evans distingue entre serviços de domínio, que encapsulam a lógica de domínio, e serviços de aplicativos, que fornecem funcionalidade técnica. Os serviços de aplicativos geralmente incluem funcionalidades técnicas, como autenticação do usuário ou envio de uma mensagem SMS. Os serviços de domínio são geralmente utilizados para modelar o comportamento que abrange múltiplas entidades.
• Eventos de domínio: Os eventos de domínio podem ser usados para notificar outras partes do sistema quando algo acontece. Como o nome sugere, os eventos de domínio devem significar algo dentro do domínio. Por exemplo, “um registo foi inserido numa tabela” não é um evento de domínio. “Uma entrega foi cancelada” é um evento de domínio. Os eventos de domínio são especialmente relevantes numa arquitetura de microsserviços. Uma vez que os microsserviços são distribuídos e não partilham arquivos de dados, os eventos de domínio fornecem uma maneira de os microsserviços se coordenarem entre si.

A equipa de desenvolvimento da Fabrikam identificou as seguintes entidades no sistema:

• Entrega
• Pacote
• Drone
• Conta
• Confirmação
• Notificação
• Etiqueta

As quatro primeiras entidades – entrega, pacote, drone e conta, são todas agregações que representam limites de consistência transacionais. Confirmações e notificações são entidades secundárias de entregas. Etiquetas são entidades secundárias de pacotes.

Os objetos de valor neste design incluem Localização, Tempo Estimado, PesoDaEncomenda e TamanhoDaEncomenda.

Existem dois eventos de domínio:

• Quando um drone está em trânsito, a entidade de drone envia eventos EstadoDoDrone que descrevem a localização e o estado do drone, por exemplo, em trânsito, pousado.
• A entidade de entrega envia eventos AcompanhamentoDaEntrega sempre que a fase de uma entrega é alterada. Estes eventos incluem EntregaCriada, EntregaReagendada, EntregaEmTrânsito e EntregaConcluída.

Observe que estes eventos descrevem coisas que são significativas no modelo de domínio. Descrevem algo sobre o domínio e não estão vinculados a uma construção de linguagem de programação específica.

A equipa de desenvolvimento identificou mais uma área de funcionalidade, que não se enquadra perfeitamente em nenhuma das entidades descritas até agora. Algumas partes do sistema devem coordenar todos os passos envolvidos no agendamento ou atualização de uma entrega. A equipa de desenvolvimento adicionou dois serviços de domínio ao design. Um Agendador coordena as etapas. Um supervisor monitora o status de cada etapa, a fim de detetar se alguma etapa falhou ou expirou.

Identificar microsserviços

Agora estamos prontos para passar do modelo de domínio para o design da aplicação. Eis uma abordagem que pode utilizar para obter microsserviços do modelo de domínio.

1. Comece com um contexto vinculado. Em geral, a funcionalidade em um microsserviço não deve abranger mais de um contexto limitado. Por definição, um contexto vinculado marca o limite de um modelo de domínio específico. Se o microsserviço misturar diferentes modelos de domínio, é sinal de que talvez seja necessário refinar a análise do domínio.
2. Em seguida, observe as agregações no modelo de domínio. As agregações geralmente são bons candidatos para microsserviços. Um agregado bem projetado mostra muitas das características de um microsserviço bem projetado:
   • Uma agregação deriva dos requisitos de negócio, em vez de questões técnicas, como acesso a dados ou mensagens.
   • Uma agregação deve ter elevada coesão funcional.
   • Uma agregação é um limite de persistência.
   • As agregações devem ser conjugadas livremente.
3. Os serviços de domínio são também bons candidatos para microsserviços. Os serviços de domínio são operações sem estado em múltiplas agregações. Um exemplo típico é um fluxo de trabalho que envolve vários microsserviços. Mais tarde, vemos um exemplo de um serviço de domínio no aplicativo Drone Delivery.
4. Finalmente, considere os requisitos não funcionais. Observe fatores como tamanho da equipa, tipos de dados, tecnologias, requisitos de escalabilidade, requisitos de disponibilidade e requisitos de segurança. Esses fatores podem levá-lo a decompor ainda mais um microsserviço em dois (ou mais) serviços menores, ou fazer o oposto e combinar vários microsserviços em um.

É importante ser pragmático e lembrar-se de que a estruturação baseada em domínio é um processo iterativo. Em caso de dúvida, comece com microsserviços mais genéricos. É mais fácil dividir um microsserviço em dois serviços menores do que refatorar a funcionalidade em vários microsserviços existentes.

Aplicar a estruturação baseada em domínio à aplicação drone

Para a aplicação da Fabrikam, todos estes serviços residem na aplicação monolítica existente. Depois de identificar onde eles podem decompor seu aplicativo em microsserviços, eles começarão com o serviço de pacote.

O serviço de pacote atualmente tem uma equipe de desenvolvimento focada, está exibindo problemas de desempenho relacionados à escalabilidade e é um ótimo candidato para iniciar a decomposição de sua aplicação.