Como projetar aplicativos com capacidade de reversão

Atualmente, estou trabalhando em um aplicativo (basicamente, é um tipo de mecanismo de execução capaz de executar tarefas definidas pelo usuário e gerar saída em tempo real) que precisa lidar com a funcionalidade de reversão, pode parecer loucura, mas é possível ter isso no aplicativo nível? por exemplo, imagine que um usuário tente executar um trabalho J1 e, uma vez iniciado, ele quisesse Editar / Modificá-lo,

- isso significa que o trabalho em execução atual deve ser eliminado,
- todas as ações executadas até agora devem ser revertidas e
- re execute o trabalho J1 novamente

algumas coisas que me vêm à mente é que, de alguma forma, devemos armazenar ou manter os estados dos aplicativos de alguma maneira, em algum lugar e depois chamar o material de reversão junto com os pontos de salvamento anteriores. Eu estava lendo alguns artigos sobre reversão no nível do banco de dados, mas o cenário não se encaixa nesse caso, pois precisa trabalhar em um ambiente de tempo real.

Mas não consigo encontrar uma abordagem adequada sobre como proceder e o que mais deve ser levado em consideração. Informe-me se isso não estiver claro. Tentarei fornecer mais informações, se possível.

Alguma ajuda ou conselho?

Sistema em tempo real ou não, o padrão de lembranças é um excelente ponto de partida.

O padrão de lembrança é um padrão de design de software que fornece a capacidade de restaurar um objeto ao seu estado anterior (desfazer via reversão).
O padrão de lembrança é implementado com três objetos: o originador, um responsável e uma lembrança.
O originador é algum objeto que possui um estado interno.
O zelador fará algo com o remetente, mas deseja poder desfazer a alteração. O zelador primeiro pede ao autor um objeto de lembrança. Em seguida, realiza qualquer operação (ou sequência de operações) que iria realizar.
Para reverter para o estado anterior às operações, ele retorna o objeto de lembrança ao originador.
O objeto de lembrança em si é um objeto opaco (aquele que o zelador não pode ou não deve mudar).
Ao usar esse padrão, deve-se tomar cuidado se o originador puder alterar outros objetos ou recursos - o padrão de lembrança opera em um único objeto.

Eu quebrei um pouco o artigo da Wikipedia para chamar a atenção para alguns itens.

Para o seu cenário, o remetente será seu código de aplicativo principal, provavelmente no ponto em que os trabalhos são registrados e iniciam o processamento.

O responsável é o que você precisa criar e pode ser algum tipo de sistema de registro ou outro armazenamento de dados.

A lembrança será a informação relevante que precisa ser desfeita e / ou refeita. Suspeito que isso pareça uma descrição de algum tipo de trabalho que possa ser colocado de volta na fila de processamento.

Se você pode agrupar as alterações existentes no trabalho J1com uma transação de banco de dados, isso cuidará das suas preocupações de reversão ( all the action taken so far must be reverted). Quando ocorre uma reversão de transação, você aciona uma chamada para o Zelador, a fim de re-enfileirar o trabalho J1.

Uma coisa a ter em mente é o último aviso no resumo da Wikipedia. Você precisa garantir que as alterações sejam atômicas e possam ser aplicadas ou revertidas como um conjunto coeso.

Não tenho certeza de que estar em um ambiente de tempo real terá muito impacto sobre como você implementa o padrão de lembrança. Se houver prazos para as atividades, talvez seja necessário traçar um perfil de algumas das alterações para garantir que o sistema responda dentro de um período de tempo apropriado. Acho que implementaria a funcionalidade primeiro e, em seguida, verifique se você está atendendo aos seus outros requisitos de aplicativo. Não prevejo que você encontre algo que invalide o que você descreveu até agora.