Usando DDD tático para projetar microsserviços

O design orientado a domínio (DDD) se opõe à ideia de ter um único modelo unificado para todo o sistema. Em vez disso, incentiva a divisão do sistema em contextos limitados, cada um com seu próprio modelo. Durante a fase estratégica do DDD, você mapeia o domínio de negócios e define contextos limitados para seus 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. Em uma arquitetura de microsserviços, onde cada contexto limitado é um candidato a microsserviço, a entidade e os padrões agregados são importantes. A aplicação desses padrões ajuda a identificar limites naturais para os serviços em seu aplicativo. Para obter mais informações, consulte Identificar limites de microsserviços. Como princípio geral, um microsserviço não deve ser menor do que um agregado nem maior do que um contexto limitado.

Este artigo analisa os padrões táticos e, em seguida, aplica-os ao contexto limitado de envio no aplicativo Drone Delivery.

Visão geral dos padrões táticos

Esta seção fornece um breve resumo dos padrões táticos de DDD. Se estiver familiarizado com o DDD, pode optar por ignorá-lo. Esses padrões são descritos com mais detalhes nos capítulos 5 e 6 do livro de Eric Evans, e em Implementing Domain-Driven Design de Vaughn Vernon.

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 seriam entidades.

• Uma entidade tem um identificador exclusivo no sistema, que pode ser usado para pesquisar ou recuperar a entidade. Isso não significa que o identificador esteja sempre exposto diretamente aos usuários. Pode ser um GUID ou uma chave primária em um banco de dados.

• Uma identidade pode abranger vários contextos limitados e pode persistir além do tempo de vida do aplicativo. Por exemplo, números de contas bancárias ou IDs emitidos pelo governo não estão vinculados a um aplicativo específico.

• Os atributos de uma entidade podem mudar ao longo do tempo. Por exemplo, o nome ou endereço de uma pessoa pode mudar, mas ela permanece a mesma pessoa.

Objetos de valor. Um objeto value não tem identidade. É definido apenas pelos valores de seus atributos. Os objetos de valor são imutáveis. Para atualizar um objeto de valor, uma nova instância é criada para substituir a antiga. Os objetos de valor podem incluir métodos que encapsulam a lógica do domínio, mas esses métodos não devem produzir efeitos colaterais ou modificar o estado do objeto. Exemplos comuns de objetos de valor incluem cores, datas e horas e valores de moeda.

Agregados. uma agregação define um limite de consistência em redor de uma ou mais entidades. Exatamente uma entidade em um agregado é a raiz. A pesquisa é feita usando o identificador da entidade raiz. Quaisquer outras entidades na agregação são filhas da raiz e são referenciadas seguindo ponteiros da raiz.

A finalidade de uma agregação é modelar invariáveis transacionais. As coisas no mundo real têm redes complexas de relações. Os clientes fazem encomendas, as encomendas contêm produtos e os produtos têm fornecedores. Se a aplicação modificar vários objetos relacionados, como garante a consistência? Como mantemos o controlo das invariáveis e as aplicamos?

Os aplicativos tradicionais costumam usar transações de banco de dados para impor consistência. Em um aplicativo distribuído, no entanto, isso muitas vezes não é viável. Uma única transação empresarial pode abranger múltiplos repositórios de dados, ser de longa duração ou envolver serviços de terceiros. Em última análise, cabe ao aplicativo, não à camada de dados, impor as invariantes necessárias para o domínio. É isso que os agregados servem de modelo.

Serviços de domínio e aplicação. na terminologia DDD, um serviço é um objeto que implementa alguma lógica sem manter nenhum 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, como autenticação de 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 notificar outras partes do sistema quando algo ocorre. Como o nome sugere, os eventos de domínio devem representar algo significativo dentro do domínio. Por exemplo, "um registro foi inserido em uma 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 importantes em uma arquitetura de microsserviços. Como os microsserviços são distribuídos e não compartilham armazenamentos de dados, os eventos de domínio permitem a coordenação entre serviços. Para obter mais informações sobre mensagens assíncronas, consulte Comunicação entre serviços.

Existem alguns outros padrões DDD não abordados aqui, incluindo fábricas, repositórios e módulos. Esses padrões podem ser úteis quando você implementa um microsserviço, mas são menos relevantes quando você projeta os limites entre microsserviços.

Entrega por drone: Aplicando os padrões

Começamos com os cenários que o contexto limitado de Envio deve lidar.

• Um cliente pode solicitar um drone para recolher mercadorias de uma empresa que esteja registada no serviço de entrega por drones.
• O remetente gera uma etiqueta (código de barras ou RFID) para colocar na embalagem.
• Um drone irá recolher e entregar um pacote do local de origem para o local de destino.
• Quando um cliente agenda uma entrega, o sistema fornece um ETA com base em informações de rota, condições meteorológicas e dados históricos.
• Quando o drone está em voo, um usuário pode rastrear a localização atual e a ETA mais recente.
• Até que um drone recolha a encomenda, o cliente pode cancelar uma entrega.
• O cliente é notificado quando a entrega é concluída.
• O remetente pode solicitar a confirmação de entrega ao cliente, sob a forma de assinatura ou impressão digital.
• Os usuários podem procurar o histórico de uma entrega concluída.

A partir desses cenários, a equipe de desenvolvimento identificou as seguintes entidades.

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

Os quatro primeiros, Entrega, Pacote, Drone e Conta, são todos agregados que representam limites de consistência transacional. Confirmações e Notificações são entidades secundárias de Entregas e Etiquetas são entidades secundárias de Pacotes.

Os objetos de valor neste design incluem Location, ETA, PackageWeight e PackageSize.

Para ilustrar, aqui está um diagrama UML do agregado Delivery. Observe que ele contém referências a outros agregados, incluindo Conta, Pacote e Drone.

Existem dois eventos de domínio:

• Quando um drone está em trânsito, a entidade Drone envia eventos EstadoDoDrone que descrevem a localização e o estado do drone (em trânsito, pousado).

• A entidade Entrega envia eventos AcompanhamentoDaEntrega sempre que a fase de uma entrega é alterada. Os eventos DeliveryTracking incluem DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff e DeliveryCompleted.

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. Portanto, a equipe de desenvolvimento adicionou dois serviços de domínio ao design: um Agendador que coordena as etapas e um Supervisor que monitora o status de cada etapa, a fim de detetar se alguma etapa falhou ou atingiu o tempo limite. Essa abordagem é uma variação do padrão Scheduler Agent Supervisor.

Próximos passos

O próximo passo é definir os limites para cada microsserviço.

Recursos relacionados

• Projeto de arquitetura de microsserviços
• Conceber uma arquitetura de microsserviços
• Utilização da análise de domínio para os microsserviços de modelo
• Escolha uma opção de computação do Azure para microsserviços