Utilizar a análise de domínios para modelar microsserviços

Um dos maiores desafios dos microsserviços é definir os limites dos serviços individuais. A regra geral é que um serviço deve fazer "uma coisa", mas colocar essa regra em prática requer um pensamento cuidadoso. Não há nenhum processo mecânico que produza o design "certo". Tem de pensar profundamente no seu domínio empresarial, requisitos e objetivos. Caso contrário, pode acabar com um design aleatório que apresenta algumas características indesejáveis, como dependências ocultas entre serviços, acoplamento apertado ou interfaces mal concebidas. Este artigo mostra uma abordagem orientada por domínios para a conceção de microsserviços.

Este artigo utiliza um serviço de entrega por drone como um exemplo em execução. Pode ler mais sobre o cenário e a implementação de referência correspondente aqui.

Introdução

Os microsserviços devem ser concebidos em torno das capacidades empresariais e não de camadas horizontais, como o acesso a dados ou mensagens. Além disso, deveriam ter acoplamento solto e alta coesão funcional. Os microsserviços são vagamente acoplados se conseguir alterar um serviço sem exigir que outros serviços sejam atualizados ao mesmo tempo. Um microsserviço é coeso se tiver um objetivo único e bem definido, como gerir contas de utilizador ou controlar o histórico de entrega. Um serviço deve encapsular conhecimentos de domínio e abstrair esse conhecimento dos clientes. Por exemplo, um cliente deve conseguir agendar um drone sem conhecer os detalhes do algoritmo de agendamento ou como a frota de drones é gerida.

A estruturação baseada em domínio (DDD) fornece uma estrutura que pode ajudá-lo a percorrer a maior parte do caminho para um conjunto de microsserviços bem estruturados. A DDD tem duas fases distintas: estratégica e tática. No DDD estratégico, está a definir a estrutura em grande escala do sistema. A DDD estratégica ajuda a garantir que a 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 irão ajudá-lo a criar microsserviços associados e coesos.

Neste artigo e no seguinte, vamos percorrer os seguintes passos ao aplicá-los à aplicação Entrega por Drone:

1. Comece por analisar 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. Em seguida, 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. Utilize os resultados do passo anterior para identificar os microsserviços na sua aplicação.

Neste artigo, abordamos os três primeiros passos, que se preocupam principalmente com o DDD. No próximo artigo, vamos identificar os microsserviços. No entanto, é importante lembrar que o DDD é um processo iterativo e contínuo. Os limites de serviço não são fixados em pedra. À medida que uma aplicação evolui, pode decidir dividir um serviço em vários serviços mais pequenos.

Cenário: Entrega por drone

A Fabrikam, Inc. está a começar um serviço de entrega por drone. A empresa gere uma frota de drones aéreos. As empresas registam-se nos serviços e os utilizadores podem requisitar um drone que venha recolher os bens para entrega. Quando um cliente agenda uma recolha, um sistema de back-end atribui um drone e notifica o utilizador do tempo de entrega estimado (ETA). Quando a entrega está em curso, o cliente pode controlar a localização do drone com um ETA atualizado de forma contínua.

Este cenário implica um domínio consideravelmente complicado. Algumas das preocupações das empresas incluem o agendamento de drones, o controlo de encomendas, a gestão de contas de utilizador e o armazenamento e a análise de dados históricos. Além disso, a Fabrikam quer chegar ao mercado sem perder tempo para, em seguida, iterar rapidamente, adicionando novas funcionalidades e capacidades. A aplicação tem de operar à escala da cloud, com um objetivo de nível de serviço (SLO) elevado. A Fabrikam também espera que as diferentes partes do sistema tenham requisitos muito diferentes no que respeita o armazenamento e a consulta de dados. Todas estas considerações levaram a Fabrikam a optar por uma arquitetura de microsserviços para a aplicação de Entrega por Drone.

Analisar o domínio

A utilização de uma abordagem DDD irá ajudá-lo a conceber microsserviços para que todos os serviços formem uma adequação natural a um requisito empresarial funcional. Pode ajudá-lo a evitar a interceção de permitir que os limites organizacionais ou as escolhas tecnológicas ditem a sua conceção.

Antes de escrever qualquer código, precisa de uma vista panorâmica do sistema que está a criar. 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 ligações. Provavelmente será um esforço colaborativo que envolve especialistas em domínio, arquitetos de software e outros intervenientes. Não precisa de utilizar nenhum formalismo específico. Desenhe um diagrama ou desenhe no quadro.

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.

Exemplo: aplicação de entrega por drone

Após alguma análise inicial do domínio, a equipa da Fabrikam criou um esboço que ilustra o domínio Entrega por Drone.

• O envio é colocado no centro do diagrama, porque é essencial para a empresa. Tudo o resto no diagrama existe para ativar esta funcionalidade.
• A gestão de drones também é fundamental para o negócio. A funcionalidade que está intimamente relacionada com a gestão de drones inclui a reparação de drones e a utilização de análise preditiva para prever quando os drones precisam de manutenção e manutenção.
• A análise do ETA fornece estimativas de tempo para recolha e entrega.
• O transporte de terceiros permitirá que a aplicação agende métodos de transporte alternativos se um pacote não puder ser enviado inteiramente por drone.
• A partilha de drones é uma possível extensão do negócio principal. A empresa pode ter capacidade excessiva de drones durante determinadas horas, e pode alugar drones que de outra forma estariam inativos. Esta funcionalidade não estará na versão inicial.
• A videovigilância é outra área para a qual a empresa poderá expandir-se mais tarde.
• As contas de utilizador, o Invoicing e o Call center são subdomínios que suportam o negócio principal.

Repare que, nesta fase do processo, ainda não tomámos nenhuma decisão sobre implementação ou tecnologias. Alguns dos subsistemas podem envolver sistemas de software externos ou serviços de terceiros. Ainda assim, a aplicação precisa de interagir com estes sistemas e serviços, pelo que é importante incluí-los no modelo de domínio.

Definir contextos vinculados

O modelo de domínio incluirá representações de coisas reais no mundo – utilizadores, drones, pacotes e assim por diante. 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, os subsistemas que lidam com a reparação de drones e a análise preditiva terão de representar muitas características físicas dos drones, como o histórico de manutenção, a quilometragem, a idade, o número do modelo, as características de desempenho, etc. 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 o tempo estimado para a recolha e entrega.

Se tentássemos criar um modelo único para ambos os subsistemas, o mesmo seria desnecessariamente complexo. Também seria mais difícil para o modelo evoluir ao longo do tempo, pois as alterações teriam de satisfazer múltiplas equipas que trabalham em subsistemas separados. Portanto, 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.

É aqui que entra em jogo o conceito DDD de contextos vinculados . 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.

Os contextos vinculados não são necessariamente isolados uns dos outros. Neste diagrama, as linhas sólidas que ligam os contextos vinculados representam locais onde dois contextos vinculados interagem. Por exemplo, o Envio depende das Contas de Utilizador para obter informações sobre os clientes e sobre a Gestão de Drones para agendar drones da frota.

No livro Domain Driven Design, Eric Evans descreve vários padrões para manter a integridade de um modelo de domínio quando interage com outro contexto vinculado. Um dos principais princípios dos microsserviços é que os serviços comunicam através de APIs bem definidas. Esta abordagem corresponde a dois padrões a que Evans chama Open Host Service e Published Language. A ideia do Open Host Service é que um subsistema define um protocolo formal (API) para outros subsistemas comunicarem com o mesmo. O Idioma Publicado expande esta ideia ao publicar a API num formulário que outras equipas podem utilizar para escrever clientes. No artigo Criar APIs para microsserviços, discutimos a utilização da Especificação OpenAPI (anteriormente conhecida como Swagger) para definir descrições de interfaces agnósticas de linguagem para APIs REST, expressas no formato JSON ou YAML.

Durante o resto deste percurso, vamos focar-nos no contexto vinculado ao Envio.

Passos seguintes

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

Recursos relacionados

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