Experiência da vida real com o Axon Framework [fechado]

https://stackoverflow.com//questions/9646884

10-12-2019
|

Pergunta

Como parte da pesquisa do CQRS para uso em um projeto, encontrei o Estrutura Axônica, e gostaria de saber se alguém tem alguma experiência na vida real com isso.Só para deixar claro, estou perguntando sobre a estrutura, não o CQRS como padrão arquitetônico.

Meu projeto já usa Spring e Spring Integration, o que se adapta perfeitamente aos requisitos do próprio Axon, mas antes de dedicar muito tempo a isso, gostaria de saber se alguém tem alguma experiência em primeira mão.Em particular, estou interessado em possíveis armadilhas que não são imediatamente aparentes na documentação.

Solução

.
A estrutura depende fortemente de eventos, o que significa que todas as alterações do estado são escritas no armazenamento de dados como eventos. "
Isso é completamente falso, não depende fortemente de fornecimento de eventos. Uma das implementações para armazenar o agregado neste quadro use o fornecimento de eventos, mas você pode facilmente usar também as classes fornecidas para usar um modelo relacional padrão.
É melhor com a terceirização de eventos.
.
Então você tem uma referência histórica de todos os seus dados. Isso é bom, mas torna a mudança do seu domínio depois de ter ido em produção uma proposta muito assustadora, especialmente se você vendeu> o cliente na "forte auditibilidade" do sistema "
Eu não acho que é muito mais fácil com um modelo relacional padrão que armazena apenas o estado atual.
.
A estrutura incentiva a denormalização de seus dados, ao ponto que alguns sugeriram> Ter uma tabela por visão no aplicativo. Isso torna sua aplicação extremamente> difícil manter, especialmente quando os desenvolvedores originais se foram "
Isso não é relacionado ao quadro, mas ao padrão arquitetônico em uso (CQRS). E desculpe mencionar que, mas ter um desnormalizador / vista é uma boa ideia, pois permanece um objeto simples.
Portanto, a manutenção é fácil porque a solicitação / inserção SQL também é fácil. Então este argumento não é muito forte. Como sobre uma exibição que usa um modelo de 1000 tabelas com junções internas em todos os lugares e consultas SQL complexas?
novamente, o CQRS ajuda porque, basicamente, os dados de exibição são apenas um seleto * da tabela que corresponde à exibição.
.
Se de alguma forma você cometeu um erro em um dos handandlers, sua única opção é> "Replay" O EventLog, que dependendo do tamanho de seus dados pode demorar um tempo muito longo. O ferramental para isso, no entanto, é inexistente.
Eu concordo com o ponto que atualmente há uma falta de ferramentas para replay eventos e que isso pode demorar muito tempo. No entanto, é teoricamente possível repetir apenas uma parte do evento e não todo o conteúdo da loja de eventos.
.
Replaying pode ter efeitos colaterais, portanto, os desenvolvedores ficam com medo de fazê-lo
Replaying Event tem efeitos colaterais -> Isso é falso. Para mim os efeitos colaterais significa modificar o estado do sistema. Em um aplicativo CQRS de eventos, o estado é armazenado na loja de eventos. Replaying Os eventos não modificam o armazenamento de eventos. Você pode ter efeito colateral no lado da consulta do modelo sim. Mas você não se importa se tiver cometido um erro porque ainda é capaz de corrigi-lo e repetir o evento mais uma vez.
.
É extremamente fácil ter desenvolvedores bagunçar usando esta estrutura. Se eles não armazenarem> Alterações para objetos de domínio em eventos, na próxima vez que você reproduzir seus eventos, você está em uma surpresa.
Bem, se você usou mal e entenda mal a arquitetura, o conceito, etc. Então ok eu concordo com você. Mas talvez o problema não seja o quadro aqui.
.
Você deve armazenar o delta? valores absolutos ? Se você não manter as guias em seus desenvolvedores> você é obrigado a acabar com os dois e você será f *** ed
Eu posso dizer que para cada sistema eu diria que não está relacionado diretamente ao próprio quadro. É como dizer: "Java é uma porcaria porque você pode estragar tudo se alguém codifica uma má implementação de métodos hashcode e igual a."
E para a última parte do seu comentário, já vi amostras como o Helloworld com a estrutura da mola. Claro que é completamente inútil em um exemplo simples.
Tenha cuidado em seu comentário para fazer a diferença entre o conceito (CQRS + EventSourcing) e a estrutura. Faça a diferença por favor.

Outras dicas

Desde que você declarou que deseja usar cqrs para o seu projeto (e eu suponho que a JVM é sua plataforma de destino), acho que o Axon Framework é uma excelente escolha.

Eu construí uma plataforma de negociação bastante complexa sobre ela (não, a amostra de negociação não é complexa) e eu não vi nenhuma falha óbvia da estrutura.

Desde que eu uso eventsourcing, as luminárias de teste tornaram muito fácil escrever o estilo BDD "dado, quando, em seguida," testes. Isso permite que você trate um agregado como uma caixa preta e concentre-se em verificar se o conjunto correto de eventos sai quando você coloca em um determinado comando.

Sobre armadilhas: antes de saltar, certifique-se de

que você tem os conceitos de CQRS descobriu.
Faça uma lista (papel, whiteboard, qualquer coisa) de todos os seus agregados, manipuladores de comando, manipuladores de eventos, sagas, comandos e eventos. Esta é a parte difícil de construir seu sistema, descobrir o que deve fazer e como. Depois disso, o manual de referência deve mostrar-lhe como ligar tudo junto com axon.
Alguns pontos específicos não axônicos:
Ser capaz de reconstruir a loja de exibição de eventos é um conceito de eventos, e não algo exclusivo para axon, mas achei muito fácil criar um serviço que me enviará todos os eventos de um tipo agregado, ID agregado ou um determinado tipo de evento.
Ser capaz de criar um novo componente de relatórios um ano após o lançamento do projeto e receber instantaneamente relatórios sobre os dados a partir do momento do lançamento do projeto e em diante é incrível.

Eu tenho utilizado o AxonFramework por mais de um ano em um projeto complexo desenvolvido para um Big Bank.

Os requisitos foram exigentes, as expectativas do cliente eram altas e libertam os tempos estreitos.

Eu escolho o AxonFramework porque, no início do projeto, foi o mais completo e a melhor implementação documentada de CQRS disponível em Java, bem projetado, fácil de integrar, para testar e estender.
Depois de mais de um ano, acho que essas considerações ainda são válidas e atuais.

Outra consideração guiou minha escolha: Eu queria que o compromisso com um projeto tão difícil se tornasse uma oportunidade de treinamento para mim e outros membros da equipe.

Começamos a desenvolver com o AxonFramework versão 1.0 e movido para a versão 1.4 como versões mais recentes foram liberadas.

Nossa experiência em equipe com CQRS e a implementação fornecida pelo AxonFramework foi absolutamente positiva.

Isso nos forneceu uma maneira consistente e uniforme para desenvolver cada característica que nos guiou e fazia você se sentir à vontade.

Sem ele algumas características do aplicativo teriam sido muito mais complicadas de se desenvolver. Estou me referindo principalmente aos vários processos de longo prazo que precisam ser manuseados e para a lógica de compensação relacionada, mas também às muitas peças de lógicas de negócios que foram necessárias, aqui e ali, que se encaixam bem e desacoplado na arquitetura de eventos promovido por CQRS.

Nossa escolha era ser conservadora no modelo de escrita, por isso preferimos uma persistência baseada no JPA em vez do evento de origem.

O modelo de consulta é composto de visualizações. Nós tentamos ter certeza de que cada visualização contém todos os dados necessários de uma única página usando visualizações intermediárias quando necessário.

De qualquer forma, desenvolvemos o modelo de gravação como estávamos aplicando a terceirização de eventos, então cuidamos de modificar o estado de agregados exclusivamente através de eventos. Quando o cliente pediu uma função de clonagem de um agregado muito complexo, era apenas uma questão de repetir os eventos de origem (com UUID traduzidos) para uma nova instância - o lado down neste caso foi o upcasting de eventos (mas esta funcionalidade foi melhorou muito na versão 2.0 iminente).

Como em cada projeto durante o desenvolvimento, encontramos muitos bugs, em nosso código principalmente, mas também em componentes supostamente maduro e estável, como o servidor de aplicativos, o contêiner do IOC, o cache, o mecanismo de fluxo de trabalho e alguns das outras bibliotecas que são facilmente encontradas em qualquer grande aplicação J2EE.

Como qualquer outro produto humano AxonFramework não era imune aos bugs também, mas surpreendentemente para um projeto jovem e nicho como este, eles têm sido poucos, não críticos e rapidamente resolvidos por novos lançamentos.

O suporte amável e imediato fornecido pelo autor na lista de discussão é outro recurso inestimável e me ajudou muito quando eu estava em apuros.

O aplicativo foi liberado na produção há um ano e atualmente é mantido e sob o desenvolvimento ativo de novos recursos.

O cliente está satisfeito e pede mais.

Quando usar o AxonFramework é mais uma questão de quando usar cqrs. Para uma resposta, vale a pena voltar para a documentação oficial: http:// www. axonframework.org/docs/1.4/introduction.html#d4e51

No nosso caso definitivamente valeu a pena.

O OP pergunta especificamente sobre as armadilhas relacionadas ao Axon Framework, e não ao CQRS.Isto torna a questão difícil de responder, já que Axon começou como uma implementação bastante fiel do famoso livro de Eric Evans

A principal vantagem é que faz exatamente o que diz na lata:ele lida com as partes difíceis de um design baseado em CQRS para você:agregados, sagas, fonte de eventos, manipuladores de comandos, manipuladores de eventos, consistência BASE etc.Ao seguir as práticas recomendadas, você terá um aplicativo altamente responsivo e escalonável horizontalmente.Se você usá-lo com fonte de eventos, seus dados serão completamente auditáveis e, pelo menos em teoria, você poderá determinar o estado que seu aplicativo tinha em um determinado momento.Ferramentas para fazer isso não são fornecidas;você terá que rolar o seu próprio.

O principal desenvolvedor do framework é muito acessível e extremamente conhecedor do assunto de alto desempenho e computação escalável em java.Ele tende a responder a todas as perguntas da lista de discussão em poucas horas. ~~Esta é uma vantagem e a principal armadilha:neste momento (início de 2014), o Axon Framework depende fortemente de uma pessoa.~~ O restante das armadilhas que gostaria de mencionar são provavelmente mais resultado do fornecimento de eventos do que do CQRS ou Axon (a partir de 2018 a estrutura é apoiada pela empresa Axoniq)

Projete seu modelo de dados com muito cuidado desde o início.Embora seja fácil de adicionar, fazer alterações fundamentais em seu modelo de dados pode ser muito difícil.Se você cometer um erro fundamental no modelo de dados, seu aplicativo poderá não funcionar bem ou até mesmo deixar de funcionar.Por exemplo, se você escolher um modelo de dados em forma de árvore, com uma raiz agregada de longa duração no topo, esse agregado poderá crescer muito à medida que acumula mais e mais eventos ao longo do tempo, e pode levar muito tempo para carregar e armazenar.Não sei o que acontecerá se isso continuar até que uma instância do agregado não caiba mais na RAM, mas imagino que possa ser ruim.Não faça assim.

Outra armadilha (relacionada ao fornecimento de eventos) é que, após uma série de revisões, pode tornar-se cada vez mais difícil raciocinar sobre o estado de um agregado, pois às vezes é preciso ter em mente não apenas o que o código faz hoje, mas também o que ele faz. fiz no passado.Isso definitivamente faz com que a repetição (de uma parte) do armazenamento de eventos para reconstruir uma tabela de visualização seja uma tarefa não trivial.

Corrigir erros de dados pode ser mais difícil do que com um design “tradicional”.Em vez de uma simples instrução SQL, muitas vezes você precisará criar um comando para alterar o estado do seu aplicativo.Se o erro em seus dados foi causado por um manipulador de eventos defeituoso, geralmente você pode apenas corrigir o bug, limpar os instantâneos e permitir que os eventos do agregado sejam reproduzidos.Se o seu bug causou a aplicação de eventos espúrios, pode haver muito mais problemas para corrigir.Os eventos defeituosos permanecerão no armazenamento de eventos e talvez seja necessário aplicar alguns novos para restaurar seus dados ao estado correto ou alterar o código para ignorar ou corrigir seu comportamento.

Eu estou atualmente com uma equipe trabalhando em uma plataforma de cassino online lançando nossa marca Casumo neste verão.O domínio e a plataforma é construir usando o Axon Framework e até agora nos serviram solidamente.

Muito tempo foi salvo não ter que construir toda a infraestrutura necessária para manuseio de comandos, roteamento de eventos, terceirização de eventos, instantâneos, etc e as APIs são muito legais para trabalhar.O único bug nós encontramos na estrutura até agora foi corrigido .. Libere 12 horas depois e Allard é sempre rápido para ter sugestões sobre novos recursos e discutir maneiras de alavancar a estrutura para cumprir suas necessidades.

Enquanto a estrutura em si é escrita decente o suficiente, o utilizando em um projeto do mundo real tem sido nada menos que um pesadelo e a escolha deste quadro IMO fosse um grande fator contribuinte para a falha deste projeto.

A estrutura depende fortemente de eventos, o que significa que todas as alterações do estado são gravadas no armazenamento de dados como eventos. Então você tem uma referência histórica de todos os seus dados. Isso é bom, mas torna a mudança de seu domínio depois de ter ido na produção uma proposta muito assustadora, especialmente se você vendeu o cliente na "forte auditibilidade" do sistema

Você não pode ter caras ops fazer alterações ad-hoc no banco de dados

A estrutura incentiva a denormalização de seus dados, ao ponto que alguns sugeriram ter uma tabela por visão no aplicativo. Isso torna sua aplicação extremamente difícil de manter, especialmente quando os desenvolvedores originais se foram

Se de alguma forma você cometeu um erro em um dos eventhandlers, sua única opção é "replay" o eventlog, que dependendo do tamanho de seus dados pode demorar muito tempo. O ferramental para isso, no entanto, é inexistente. Replaying pode ter efeitos colaterais, então os desenvolvedores ficam com medo de fazê-lo

É extremamente fácil ter desenvolvedores bagunçar usando esta estrutura. Se eles não armazenarem alterações para objetos de domínio em eventos, a próxima vez que você reproduzir seus eventos, você estiver em uma surpresa. Você deve armazenar o Delta? valores absolutos ? Se você não ficar guias em seus desenvolvedores, você é obrigado a acabar com os dois e você será f *** ed

Não há praticamente nenhuma adoção deste quadro, então googling para respostas não fará qualquer bom

Mesmo que a estrutura ainda não suporte a distribuição, ela é escrita com isso em mente e as API são uma dor para trabalhar por causa disso. Deixando um evento é assíncrise por padrão e se você deseja verificar se uma exceção foi levantada executando o comando, digamos uma exceção de nome de usuário duplicado, você precisa passar em um ouvinte para o seu commandhandler, que é um futuro, então você espera pelo futuro Resultado para entrar, lidar com quaisquer exceções verificadas, interuptedException etc e, em seguida, você pode pegar a exceção que foi lançada do futuro. OfCourse que exceções um comando pode aumentar não é aparente da API. Derrotar o propósito das exceções verificadas

Confira alguns dos Exemplo de aplicativos . De alguma forma, preciso de um ouvinte de unidade de trabalho para criar um aplicativo de livro de endereços? Minha bondade ...

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow