Há muitos boas razões para construir sistemas baseados em event sourcing e CQRS, e alguns dos benefícios são apenas possíveis em sistemas dessa natureza. Mas também há problemas que aparecem apenas depois que a aplicação está em produção (desafios pós implantação). Em uma apresentação na conferência Event-driven Microservices, organizada pela AxonIQ, Joris Kuipers compartilhou sua experiência desenvolvendo e evoluindo aplicações baseadas em CQRS e event sourcing em produção.
Para Kuipers, CTO da Trifork Amsterdam, um problema comum é que sistemas são construídos dessa forma precocemente, antes de ser realmente possível entender o domínio. Posteriormente, mais conhecimento sobre o domínio é adquirido e esses novos conhecimentos forçam os modelos a mudar. Entretanto, nesse momento há eventos mapeados a certos agregados que não suportam os novos modelos. Isso exige um refactoring que pode ser bem difícil de se implementar.
Se um sistema está sendo construído de forma tradicional, onde apenas o estado atual é persistido, geralmente é fácil alterar o estado da aplicação em uma atualização; normalmente, o único necessário a fazer é rodar algumas instruções SQL durante a implantação da aplicação. Quando uma aplicação CQRS ou event sourced é atualizada, isso não se aplica. Tipicamente, as novas funcionalidades irão publicar novos tipos de eventos e novas versões dos eventos existentes. Para minimizar os problemas nesse tipo de cenário, Kuipers se refere à lei de Postel, um princípio que diz:
Seja conservativo no que você envia, seja liberal no que você aceita.
Para uma aplicação event sourced, isso significa que deve se ser conservativo e consistente quando emitindo eventos, porém liberal no que se aceita aceita; evitando validação de schemas e permitindo informações desconhecidas. Kuipers enfatiza que ser liberal também inclui os seus próprios eventos, sejam do passado ou do futuro. É muito importante que tanto as velhas quantos as novas versões de uma aplicação event sourced possam coexistir à medida que evoluem.
Ao consumir eventos externos, ignorar tipos de eventos desconhecidos e campos desconhecidos de um evento geralmente funciona, mas Kuipers lembra que isso é apenas uma regra geral; há exceções e o desenvolvedor deve tomar uma decisão consciente. No consumo de eventos internos isto é mais complexo. Em deploys blue-green e no caso de rollbacks, quando uma nova versão não está se comportando corretamente, diferentes versões de um evento podem ter sido persistidas, o que exige compatibilidade na leitura desses eventos. Na experiência de Kuiper, isto é extremamente difícil e por isso, geralmente, as empresas aceitam algum downtime. Se possível, Kuipers recomenda o roll-forward - executar deploys pequenos e frequentes, e no caso de um problema uma correção pode ser feita e o deploy de uma versão executado.
Um problema no consumo de eventos públicos é que os eventos geralmente são produzidos através do mapeamento de classes específicas para JSON e XML, e então consumidos de volta através do mesmo mapeamento. Isto pode causar problemas em sistemas externos para novos tipos de eventos e para sistemas construídos em outras plataformas. A utilização de metadados e annotations são geralmente úteis para mitigar esse tipo de problema.
Separar eventos internos de eventos externos é algo que Kuipers acha muito útil porque os mesmos possuem necessidades diferentes. Eventos públicos devem ser mais estáveis e devem aderir a contratos e acordos similares; campos não podem simplesmente serem removidos ou terem os tipos ou os significados alterados. Eventos internos nunca são publicamente expostos, o que significa que temos o controle total sobre todas as partes que tratam desse evento simplificando qualquer alteração necessária.
Com uma nova versão de uma aplicação, agregados podem necessitar de alguns dados a mais e, para Kuipers, isto é resolvido bem quando CQRS e event sourcing são utilizados. Inicialmente, os agregados podem ter um estado mínimo, apenas o suficiente para suportar a lógica de negócio. Mas à medida que a necessidade por mais dados aumenta, mais estado pode ser adicionado aos agregados correspondentes e, devido ao poder do event sourcing, o novo estado parecerá que estava lá desde o começo.
Snapshots são comumente utilizados por questões de otimização para guardar o estado atual dos agregados, mas quando um agregado é alterado um novo snapshot deve ser criado. Uma técnica que funciona em sistemas com poucos eventos é apenas excluir todos snapshots e recriar novos à medida que forem necessários. Em sistemas no qual a quantidade de eventos persistidos é muito grande, os snapshots necessitam ser recriados à medida que são alterados, o que pode exigir algum ferramental extra.
Para projeções de queries, uma técnica similar aos de snapshots pode ser utilizada. Em sistemas com poucos eventos, as projeções podem ser recriadas reprocessando todos os eventos. Em sistemas com muitos eventos, uma técnica melhor é atualizar as projeções. Um jeito de se fazer isso é utilizar comandos e eventos específicos para a fase de atualização.
Kuipers conclui encorajando as pessoas com vasta experiência em sistemas event sourced para compartilhar suas experiências com outros. O que significa ter uma aplicação rodando por cinco anos, utilizando agregados com event sourcing desde o início? Como evoluir, manter, e publicar novas versões de sistemas desse tipo?
As apresentações da conferência foram gravadas e serão disponibilizadas publicamente nas próximas semanas.