Durante a fase estratégica do design orientado por domínios (DDD), está a mapear o domínio empresarial e a definir contextos vinculados para os 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. Numa arquitetura de microsserviços, estamos particularmente interessados na entidade e nos padrões de agregação. A aplicação destes padrões irá ajudar-nos a identificar limites naturais para os serviços na nossa aplicação (veja o próximo artigo nesta série). 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. Primeiro, vamos rever os padrões tácticos. Em seguida, iremos aplicá-los ao contexto vinculado ao Envio na aplicação Entrega por Drone.
Descrição geral dos padrões táticos
Esta secção fornece um breve resumo dos padrões de DDD táticos, pelo que, se já estiver familiarizado com o DDD, provavelmente pode ignorar esta secção. Os padrões são descritos mais detalhadamente nos capítulos 5 – 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 utilizado para procurar ou obter a entidade. Isso não significa que o identificador seja sempre exposto diretamente aos utilizadores. Pode ser um GUID ou uma chave primária numa base de dados.
- Uma identidade pode abranger vários contextos vinculados e pode perdurar para além da duração da aplicação. Por exemplo, os números de contas bancárias ou IDs emitidos pelo governo não estão associados à duração de uma determinada aplicação.
- Os atributos de uma entidade podem ser alterados ao longo do tempo. Por exemplo, o nome ou endereço de uma pessoa pode mudar, mas continua a ser a mesma pessoa.
- Uma entidade pode conter referências a outras entidades.
Objetos de valor. Um objeto de valor não tem identidade. É definido apenas pelos valores dos respetivos atributos. Os objetos de valor também são imutáveis. Para atualizar um objeto de valor, crie sempre uma nova instância para substituir a antiga. Os objetos de valor podem ter métodos que encapsulam a lógica de domínio, mas esses métodos não devem ter efeitos colaterais no estado do objeto. 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 redor de uma ou mais entidades. Exatamente uma entidade numa agregação é a raiz. A pesquisa é feita com o identificador da entidade raiz. Todas as outras entidades no agregado são subordinadas da raiz e são referenciadas ao seguir os 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 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?
As aplicações tradicionais utilizam frequentemente transações de bases de dados para impor a consistência. No entanto, numa aplicação distribuída, isso muitas vezes não é viável. Uma única transação empresarial pode abranger vários arquivos de dados ou pode ser de execução prolongada ou envolver serviços de terceiros. Em última análise, cabe à aplicação, não à camada de dados, impor os invariantes necessários para o domínio. É isso que os agregados servem para modelar.
Nota
Uma agregação pode consistir numa única entidade, sem entidades subordinadas. O que o torna agregado é o limite transacional.
Serviços de domínio e aplicações. na terminologia DDD, um serviço é um objeto que implementa alguma lógica sem manter nenhum estado. O Evans distingue entre os serviços de domínio, que encapsulam a lógica de domínio e os serviços de aplicações, que fornecem funcionalidades técnicas, como a autenticação de utilizadores ou o envio de uma mensagem SMS. Os serviços de domínio são geralmente utilizados para modelar o comportamento que abrange múltiplas entidades.
Nota
O termo serviço está sobrecarregado no desenvolvimento de software. A definição aqui não está diretamente relacionada com microsserviços.
Eventos de domínio. os eventos de domínio podem ser utilizados 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. O artigo Comunicação entre serviços aborda as mensagens assíncronas mais detalhadamente.
Existem alguns outros padrões DDD não listados aqui, incluindo fábricas, repositórios e módulos. Estes podem ser padrões úteis para quando está a implementar um microsserviço, mas são menos relevantes ao conceber os limites entre microsserviços.
Entrega de drones: Aplicar os padrões
Começamos pelos cenários que o contexto vinculado ao Envio tem de processar.
- Um cliente pode pedir a um drone que recolha bens de uma empresa registada no serviço de entrega de drones.
- O remetente gera uma etiqueta (código de barras ou RFID) para colocar no pacote.
- Um drone irá recolher e entregar um pacote da localização de origem para a localização 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 utilizador pode controlar a localização atual e o ETA mais recente.
- Até que um drone tenha recolhido o pacote, o cliente pode cancelar uma entrega.
- O cliente é notificado quando a entrega é concluída.
- O remetente pode pedir confirmação de entrega ao cliente, na forma de uma impressão de assinatura ou de dedo.
- Os utilizadores podem procurar o histórico de uma entrega concluída.
Nestes cenários, a equipa de desenvolvimento identificou as seguintes entidades.
- Entrega
- Pacote
- Drone
- Conta
- Confirmação
- Notificação
- Etiqueta
Os primeiros quatro, 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 nesta estrutura incluem Localização, ETA, PackageWeight e PackageSize.
Para ilustrar, segue-se um diagrama UML da agregação entrega. Tenha em atenção que 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. Estes 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. Por conseguinte, a equipa de desenvolvimento adicionou dois serviços de domínio à estrutura: um Scheduler que coordena os passos e um Supervisor que monitoriza o estado de cada passo, para detetar se algum passo falhou ou excedeu o tempo limite. Esta é uma variação do padrão do Supervisor do Agente do Scheduler.
Passos seguintes
O próximo passo é definir os limites para cada microsserviço.