Apesar de abordagens poderosíssimas, microservices e modelos reativos trazem junto de si a incerteza de não se saber, em nenhum momento, onde as coisas estão. Os sistemas orientados a mensagens podem levar desenvolvedores a se questionar sobre alguns pontos aparentemente simples:
- Alguém recebeu minha mensagem?
- Alguém respondeu minha mensagem?
- As mensagens foram recebidas fora de ordem?
Falando durante uma apresentação de keynote na conferência Explore DDD, Vaugh Vernon disse entender tais dúvidas e reagir aos resultados é a essência do Domain-Driven Design. Utilizar uma Linguagem Ubíqua (Ubiquitous Language) para descrever um sistema composto de Contextos Delimitados (Bounded Contexts) ajuda a encarar a complexidade de sistemas distribuídos. Os conceitos de incerteza, especialmente sobre comunicação entre contextos delimitados, precisam se tornar parte da linguagem ubíqua.
Vernon, autor do Implementando Domain-Driven Design e Reactive Messaging Patterns with the Actor Model, disse que criar um bom mapa de contexto é vital para um projeto. Falando em termo práticos, diz que sempre haverá múltiplos Contextos Delimitados no domínio principal de um negócio, e cabe ao mapa de contexto mostrar as relações entre esses contextos delimitados. Ao desenhar um mapa de contexto, devemos focar em entender as relações da equipe entre contextos, ao invés de detalhes técnicos, como o uso de REST ou RPC. Na palavras de Vernon:
"Com quem você está integrando é mais importante do que como você está integrando."
Vernon enxerga uma tendência nos sistemas reativos, onde o comportamento reativo existe internamente, e estende além, em um único microservice. Segundo ele, isso não é totalmente novo, e Vernon afirma que Eric Evans estava à frente da indústria ao advogar padrões de eventos. A ideia básica é reagir a eventos que aconteceram no passado, e então deixar o estado em harmonia.
With microservices and reactive behavior comes uncertainty, including uncertainty about what order events might be delivered in, and the possibility of events being delivered twice. Vernon cautions that, "Even if you're using a messaging system like Kafka, and you think you're going to consume them in sequential order, you're fooling yourself. If there is any possibility of any message being out of order, you have to plan for all of them being out of order."
Com microservices e comportamento reativo vieram também incertezas, incluindo incerteza sobre em qual ordem os eventos devem ser entregues, e a possibilidade de eventos serem entregues de forma duplicada. Vernon alerta que:
"Mesmos que estejamos usando um sistema de mensagens como o Kafka, e pensamos em consumí-los em uma ordem sequencial, estaremos nos enganando. "Se há qualquer possibilidade de uma mensagem ser entregue fora da ordem, temos de planejar considerando que todos estão fora de ordem."
Vernon acredita que essas incertezas são difíceis de lidar, pois nos tornamos "viciados" em ideias como bloqueio de chamadas, aguardar a ordem certa das coisas, e bloquear o banco de dados. Nos sistemas reativos, essas crenças de longa data começam a cair. Enquanto o instinto de um desenvolvedor será criar um façade que esconde as incertezas e permitir que o código se comporte tradicionalmente, como software não reativo, Vernon diz que a abordagem exatamente oposta deve ser usada.
Ele resume sua abordagem em lidar com incertezas como "Menos Query; Mais Evento.". Eventos nos mostram o que aconteceu em um específico ponto no tempo. Não sabemos o estado do sistema agora, sabemos apenas o estado quando o evento acontece, e o que mudou. Como reagir a esses eventos, incluindo quando eles acontecem fora de ordem, deve ser uma decisão de negócios, discutia usando a linguagem ubíqua. Ele cita o artigo de Pat Helland, Life Beyond Distributed Transactions:
"Em sistemas que não podem contar contar transações distribuídas, o gerenciamento de incertezas deve ser implementado na lógica de negócios."
Vernon descreveu diversos cenários com diferentes formas de incerteza, e incluiu breves exemplos de código para manipulá-los. No entanto, ele enfatizou que o código apenas mostrou uma implementação que precisa ser uma decisão de negócios. Os negócios devem abraçar uma mentalidade que considera incertezas e que deve ser modelada na abertura, com decisores de negócio, não dentro de equipes de desenvolvimento de software. Não tente criar uma fachada (façade) que te permite pensar que não está em um estado de incerteza. Ao invés disso, faça o melhor trabalho e modele as incertezas.
Nota do Editor: Uma versão anterior dessa história creditou erroneamente que o conceito de Eventos de Domínio (Domain Events) foi introduzido por Eric Evans no seu Domain-Driven Design.