Em uma série de posts, Mathias Verraes descreve patterns (padrões) em sistemas distribuídos que encontrou em seu trabalho e achou útil. Seu objetivo é identificar e documentar padrões juntamente com o contexto em que podem ser úteis. Quanto ao contexto, ele enfatiza que os padrões, geralmente se tornam antipadrões quando usados no contexto errado.
Verraes, que trabalha como consultor e é fundador/organizador de uma conferência Europeia sobre Domain-Driven Development (DDD), descreve 16 padrões em três grandes áreas: padrões de desacoplamento, padrões gerais de mensagens e padrões de event sourcing. Para cada padrão, ele descreve o problema e sua solução, incluindo exemplos e algumas vezes implementações. Resumimos a seguir uma seleção.
Padrões de desacoplamento
O padrão Garantia de integralidade (Completeness Guarantee) é voltado ao desacoplamento. Tem o objetivo de definir o conjunto de eventos de domínio enviados por um produtor, em que um consumidor precisa reproduzir o estado do produtor. Frequentemente, eventos são criados ou atualizados em resposta às necessidades do consumidor e, depois de algum tempo, fica difícil compreender a finalidade de cada evento e confirmar se é usado por um consumidor. Para alcançar a integralidade, um evento deve ser publicado sempre que o estado for alterado no produtor, e esse evento deve conter apenas atributos alterados, nada mais. Assim fica claro o que cada evento significa e quais atributos contém.
Evento de Passagem de Tempo é outro padrão de desacoplamento que visa substituir um agendador (scheduler) que chama uma API em um serviço com um agendador que emite eventos de domínio genéricos, como DiaPassou ou MêsPassou. Serviços interessados podem então ficar 'ouvindo' esses eventos e lidar internamente com as ações relacionadas. Para Verraes, esta é, porém, uma abordagem muito reativa. Em vez de enviar um comando e esperar uma resposta, um agendador pode apenas emitir eventos sobre a passagem do tempo, sem se preocupar se alguém os está escutando.
Padrões de separação de eventos
O padrão Eventos Públicos Explícitos permite separar eventos em privados e públicos. Muitas vezes, um serviço, especialmente quando é usado o event sourcing, não deve publicar todos os eventos para o mundo externo. Se o fizesse, a API externa do serviço ficaria fortemente acoplada à estrutura interna e alterações internas exigiriam prováveis modificações na API e em outros serviços. O padrão pode ser implementado ao tornar todos os eventos privados por padrão, e marcando especificamente os que são públicos. Eventos privados e públicos podem ser publicados usando canais de mensagens separados.
Camadas de Eventos Segregados é uma maneira de separar ainda mais os eventos privados dos públicos. Nesse padrão, são criados adaptadores que escutam eventos internos e emitem um fluxo de novos eventos públicos. Dessa maneira, os eventos internos se tornam estritamente privados. Verraes observa que esse é um padrão de implementação para construir um camada anticorrupção. Com o padrão, o novo fluxo de eventos se torna, na prática, um novo contexto limitado (bounded context), com seus próprios tipos e nomes de eventos.
Padrões de segurança e privacidade
Quando existem atributos em um evento que só devem ser visíveis para alguns consumidores, pode ser útil o padrão Payloads Esquecíveis (Forgettable Payloads). Aqui, informações confidenciais em um evento são substituídas por uma URL apontando para um repositório de dados de acesso restrito contendo as informações confidenciais.
Outro padrão similar é o Crypto-Shredding, em que informações confidenciais são criptografadas com uma chave diferente para cada recurso. Se a chave for excluída, as informações correspondentes não podem mais ser acessadas.
O padrão Rastreamento de Decisões é usado para armazenar o resultado das decisões quando for usado event sourcing. Se uma regra for alterada e os eventos forem reproduzidos sem considerar as alterações da regra, o resultado poderá ser diferente. Uma solução é armazenar decisões na forma de eventos, juntamente com os eventos que levaram à decisão. Verraes observa que esse padrão também pode ser usado para reduzir o impacto de um bug, já que permite reproduzir eventos e comparar resultados com dados do evento de decisão.
Padrões gerais de mensagens
O Natural Language Message Names é um padrão recomendando que verbos sejam usados em nomes de mensagens para torná-los mais expressivos. Usar uma linguagem natural e incorporá-la no código e nos artefatos é um conceito central no DDD. Verraes observa que os especialistas no domínio não usam termos como "evento de pagamento" ou "fatura paga"; dizem "a fatura foi paga". Para eventos, ele recomenda o uso de nomes como ClienteFoiCobrado e FaturaFoiPaga. Para comandos, prefere nomes como CobrarCliente e ConcluirVenda.
Outros padrões e mais informações
Verraes conclui observando que sua série de padrões é só um começo, e que há muitos outros padrões a se documentar e descobrir. De forma similar, Chris Richardson criou uma linguagem padrão para microservices, com padrões sobre implantação, estilos de comunicação, gerenciamento de dados e outras áreas.