Como usar análise de domínio para modelar microsserviços

Um dos maiores desafios de microsserviços é definir os limites de serviços individuais. A regra geral é que um serviço deve fazer apenas uma coisa, mas colocar essa regra em prática requer um pensamento cuidadoso. Não há nenhum processo mecânico que produza o design correto. Você precisa pensar profundamente sobre seu domínio de negócios, requisitos, características de arquitetura (também conhecidas como requisitos não funcionais) e metas. Caso contrário, você pode terminar com um design aleatório que exibe algumas características indesejáveis, como dependências ocultas entre serviços, acoplamento rígido ou então interfaces mal projetadas. Este artigo mostra uma abordagem orientada por domínio para criar microsserviços. A avaliação dos limites de serviço é um esforço contínuo na evolução das cargas de trabalho. Às vezes, a avaliação resulta em definições redefinidas de limites existentes que exigem mais desenvolvimento de aplicativos para acomodar as alterações.

Este artigo usa um serviço de entrega por drones como um exemplo em execução. Para obter mais informações sobre o cenário e a implementação de referência correspondente, consulte Criar uma arquitetura de microsserviços.

Introdução

Microsserviços devem ser criados em torno de capacidades comerciais, não de camadas horizontais como acesso a dados ou mensagens. Além disso, eles devem ter um acoplamento flexível e alta coesão funcional. Os microsserviços serão acoplados vagamente se você puder alterar um serviço sem exigir que outros serviços sejam atualizados ao mesmo tempo. Um microsserviço será coeso se tiver uma finalidade única e bem definida, como gerenciar contas de usuário ou acompanhar o histórico de entrega. Um serviço deve encapsular o conhecimento do domínio e abstrair esse conhecimento de clientes. Por exemplo, um cliente deve ser capaz de agendar um drone sem conhecer os detalhes do algoritmo de agendamento ou como a frota de drones é gerida. As características da arquitetura devem ser definidas para cada microsserviço para corresponder às suas preocupações de domínio, em vez de serem definidas para todo o sistema. Por exemplo, um microsserviço voltado para o cliente pode precisar ter desempenho, disponibilidade, tolerância a falhas, segurança, testabilidade e agilidade. Um microsserviço de back-end pode precisar ter apenas tolerância a falhas e segurança. Se os microsserviços tiverem comunicações síncronas entre si, a dependência entre eles geralmente produz a necessidade de compartilhar as mesmas características de arquitetura.

O DDD (design orientado por domínio) fornece uma estrutura que pode ajudar você pela maior parte do processo de obtenção de um conjunto de microsserviços bem projetado. O DDD tem duas fases diferentes, a estratégica e a tática. No DDD estratégico, você define a estrutura em grande escala do sistema. O DDD estratégico ajuda a garantir que sua arquitetura permaneça concentrada em capacidades comerciais. O DDD tático fornece um conjunto de padrões de design que você pode usar para criar o modelo de domínio. Esses padrões incluem entidades, agregações e serviços de domínio. Esses padrões táticos ajudam você a criar microsserviços que são flexívelmente acoplados e coesos.

Neste artigo e no próximo, examinaremos as etapas a seguir, as aplicaremos ao aplicativo de Entrega por Drone:

1. Comece analisando o domínio empresarial para entender os requisitos funcionais do aplicativo. A saída desta etapa é uma descrição informal do domínio, que pode ser refinada em um conjunto mais formal de modelos de domínio.

2. Em seguida, defina os contextos limitados do domínio. Cada contexto limitado contém um modelo de domínio que representa um subdomínio específico do aplicativo maior.

3. Dentro de um contexto limitado, aplique padrões DDD táticos para definir entidades, agregações e serviços de domínio.

4. Use os resultados da etapa anterior para identificar os microsserviços em seu aplicativo.

Neste artigo, abordaremos as três primeiras etapas, que se relacionam principalmente com DDD. No próximo artigo, identificaremos os microsserviços. No entanto, é importante lembrar que DDD é um processo iterativo e em andamento. Limites de serviço não são fixos de forma imutável. À medida que um aplicativo evolui, você pode decidir dividir um serviço em vários serviços menores.

Cenário: Entrega por drone

A Fabrikam, Inc. está dando início a um serviço de entrega por drone. A empresa gerencia uma frota de aeronaves de tipo drone. Empresas se registram no serviço e os usuários podem solicitar que um drone colete mercadorias para entrega. Quando um cliente agenda uma coleta, um sistema de back-end atribui um drone ao usuário e notifica-o com um tempo de entrega previsto. Enquanto a entrega está em andamento, o cliente pode acompanhar a localização do drone, com um ETA atualizado continuamente.

Esse cenário inclui um domínio bastante complexo. Algumas das principais preocupações comerciais incluem agendamento de drones, acompanhamento de pacotes, gerenciamento de contas de usuário e armazenamento e análise de dados históricos. A Fabrikam também pretende entrar no mercado e iterar rapidamente, adicionando novas funcionalidades e recursos. O aplicativo deve operar em escala de nuvem e atender a um objetivo de alto nível de serviço. Além disso, a Fabrikam espera que diferentes partes do sistema tenham requisitos variados para armazenamento e consulta de dados. Essas considerações levam a Fabrikam a adotar uma arquitetura de microsserviços para o aplicativo de Entrega de Drones.

Analisar o domínio

Uma abordagem DDD ajuda você a criar microsserviços para que cada serviço forme um ajuste natural a um requisito de negócios funcional. Ele pode lhe ajudar a evitar a armadilha de permitir que os limites organizacionais ou opções de tecnologia ditem o seu design.

Antes de escrever qualquer código, você deve ter uma compreensão de alto nível do sistema que você cria. O DDD começa modelando o domínio de negócios e criando um modelo de domínio. O modelo de domínio é um modelo abstrato do domínio empresarial. Ele destila e organiza o conhecimento de domínio e fornece uma linguagem comum para desenvolvedores e especialistas em domínio.

Comece mapeando todas as funções de negócios e suas conexões. Esse esforço pode ser uma colaboração que inclui especialistas em domínio, arquitetos de software e outros stakeholders. Você não precisa usar nenhum formalismo específico. Esboce um diagrama ou desenhe em um quadro branco.

Ao preencher o diagrama, você pode começar a identificar subdomínios discretos. Quais funções estão intimamente relacionadas? Quais funções são fundamentais para o negócio e quais funções fornecem serviços auxiliares? Qual é o grafo de dependência? Durante a fase inicial, você não se importa com tecnologias ou detalhes de implementação. Dito isto, você deve observar o local em que o aplicativo precisa se integrar a sistemas externos, como gerenciamento de relacionamento com o cliente, processamento de pagamento ou sistemas de cobrança.

Exemplo: o aplicativo de entrega por drone

Após algumas análises de domínio iniciais, a equipe da Fabrikam criou um esboço aproximado que representa o domínio de Entrega por Drones.

• O envio é colocado no centro do diagrama, porque ele é fundamental para o negócio. Tudo no diagrama existe para habilitar essa funcionalidade.
• O gerenciamento de drones também é fundamental para o negócio. A funcionalidade que está intimamente relacionada ao gerenciamento de drones inclui reparo de drones e uso de análise preditiva para prever quando os drones precisam de manutenção e manutenção.
• A análise de ETA fornece estimativas de tempo para retirada e entrega.
• O transporte de terceiros permitirá que o aplicativo agende métodos de transporte alternativos se um pacote não puder ser enviado inteiramente por drone.
• O compartilhamento de drones é uma possível extensão do negócio principal. A empresa pode ter excesso de capacidade de drones durante certas horas, e poderia alugar drones que de outra forma estariam ociosos. Este recurso não estará na versão inicial.
• A vigilância por vídeo é outra área para a qual a empresa pode se expandir mais tarde.
• Contas de usuário, Faturamento e Call center são subdomínios que dão suporte ao negócio principal.

Observe que neste momento no processo, não tomamos nenhuma decisão sobre implementação ou tecnologias. Alguns dos subsistemas podem envolver sistemas de software externos ou serviços de terceiros. Mesmo assim, o aplicativo deve interagir com esses sistemas e serviços, portanto, é importante incluí-los no modelo de domínio.

Definir contextos limitados

O modelo de domínio inclui representações de objetos reais no mundo – usuários, drones, pacotes e assim por diante. Mas isso não significa que todas as partes do sistema precisam usar as mesmas representações para as mesmas coisas.

Por exemplo, subsistemas que lidam com reparo de drones e análise preditiva precisarão representar muitas características físicas dos drones, como histórico de manutenção, quilometragem, idade, número do modelo e características de desempenho. Porém, quando é hora de agendar uma entrega, esses elementos não importam. O subsistema de agendamento só precisa saber se um drone está disponível e o ETA para coleta e entrega.

Se tentássemos criar um único modelo para ambos esses subsistemas, ele seria desnecessariamente complexo. Também seria mais difícil para o modelo evoluir ao longo do tempo, porque as alterações precisariam atender a várias equipes trabalhando em subsistemas separados. Portanto, geralmente é melhor criar modelos separados que representam a mesma entidade do mundo real (nesse caso, um drone) em dois contextos diferentes. Cada modelo contém apenas os recursos e os atributos que são relevantes no contexto específico dele.

O conceito DDD de contextos limitados entra em jogo aqui. Um contexto limitado define o limite dentro de um domínio em que um modelo de domínio específico se aplica. Referindo-se ao diagrama anterior, você pode agrupar a funcionalidade com base em se funções diferentes compartilham o mesmo modelo de domínio.

Contextos limitados não são necessariamente isolados uns dos outros. Neste diagrama, as linhas sólidas, conectando os contextos limitados representam lugares onde dois contextos limitados interagem. Por exemplo, o envio depende de contas de usuário para obter informações dos clientes e do gerenciamento de drones para agendar drones da frota.

No livro Design Controlado pelo Domínio, Eric Evans descreve vários padrões para manter a integridade de um modelo de domínio quando ele interage com outro contexto limitado. Um dos principais princípios de microsserviços é que os serviços se comunicam por meio de APIs bem definidas. Essa abordagem corresponde a dois padrões que Evans chama de serviço de host aberto e linguagem de programação publicada. A ideia de serviço de host aberto é que um subsistema define um protocolo formal (API) para outros subsistemas se comunicarem com ele. A linguagem de programação publicada estende essa ideia publicando a API de uma forma que outras equipes podem usar para escrever código de clientes. No artigo Criando APIs para microsserviços, discutimos o uso da Especificação OpenAPI (anteriormente conhecida como Swagger) para definir descrições de interface independente de linguagem para APIs REST, expressas no formato JSON ou YAML.

Para o restante dessa jornada, nos concentraremos no contexto limitado de remessa.

Próximas etapas

Depois de concluir uma análise de domínio, o próximo passo é aplicar o DDD tático, para definir seus modelos de domínio com mais precisão.

Recursos relacionados

• Design da arquitetura de microsserviços
• Criar uma arquitetura de microsserviços
• Identificar limites de microsserviço
• Escolher uma opção de computação do Azure para microsserviços