Conceitos
Event sourcing: estado como sequência de eventos
Intuição
Pense num extrato bancário: o saldo diz onde você está agora, mas só a lista de depósitos e saques mostra como chegou lá. Se alguém descobre que um lançamento antigo estava errado, dá para corrigir esse lançamento e refazer as contas a partir dele, em vez de tentar adivinhar o estrago. Event sourcing registra todo o histórico de mudanças, e o saldo passa a ser algo que sempre se pode recalcular a partir dele.
Como funciona
Event sourcing garante que toda mudança no estado da aplicação fique registrada como uma sequência de eventos, e que todas as mudanças nos objetos de domínio sejam iniciadas por esses eventos. Como o estado é derivável do log, ele pode ser descartado e refeito reexecutando os eventos numa aplicação vazia; a consulta temporal parte conceitualmente de um estado em branco e reexecuta os eventos até certo instante ou certo evento. No replay, se um evento passado estava incorreto, reverte-se esse evento e os posteriores e reaplicam-se o corrigido e os seguintes, ou descarta-se o estado e reproduz-se todo o log com o evento correto no lugar; a mesma técnica serve para eventos que chegaram fora de ordem. Reconstruir tudo do zero é lento quando há muitos eventos, então o estado atual pode ser mantido em cache, em memória ou em disco, a partir de snapshots: o sistema começa de um snapshot anterior e reproduz os eventos desde ali, e novos snapshots podem ser feitos em paralelo sem parar a aplicação. O sistema de registro oficial pode ser o log (os bancos são construídos a partir dele) ou o estado atual (e os eventos servem só para auditoria e processamento especial). Reverter eventos é mais simples quando o evento é uma diferença (somar 10 à conta) do que um valor final (definir a conta como 110), que não guarda o valor anterior; também é possível voltar a um snapshot passado e reproduzir. Como replays acontecem à vontade, sistemas externos que não distinguem replay de processamento real são encapsulados num Gateway que sabe quando o processador está em replay, e em rebuilds e consultas temporais costuma bastar desativá-lo; consultas externas, como a taxa de câmbio do dia do evento, exigem dados históricos ou um gateway que lembre as respostas. Novas funcionalidades e correções de bugs no que é interno podem ser aplicadas reprocessando os eventos, mas com gateways externos é preciso rastrear a diferença entre o que aconteceu com o bug e sem ele, e regras que mudam com o tempo precisam entrar no próprio modelo de domínio, o que pode deixar o comportamento bitemporal bagunçado.
Na prática
Fowler reconhece que empacotar toda mudança como evento não é uma escolha natural, e que a técnica só vale a pena se houver retorno. Os retornos que ele cita são o log de auditoria, a depuração (reproduzir eventos reais num ambiente de teste, parando e voltando como num depurador) e os padrões Parallel Models e Retroactive Events, que exigem a técnica; como é muito difícil adaptar Event Sourcing depois a um sistema que não nasceu assim, Fowler recomenda adotá-lo desde já se esses padrões forem prováveis. O próprio autor adverte que o texto é material em rascunho de meados dos anos 2000.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.