Cómo diseñar aplicaciones con capacidad de reversión

Actualmente estoy trabajando en una aplicación (básicamente es un tipo de motor de ejecución capaz de ejecutar trabajos definidos por el usuario y generar resultados en tiempo real) que necesita manejar la funcionalidad de reversión, puede sonar loco pero es posible tener tal cosa en la aplicación ¿nivel? por ejemplo, imaginar algunos intentos usuario ejecute un trabajo J1 y una vez que se comenzó a ejecutar quería Editar / Modificar ella,

- que el trabajo mediante la corriente de funcionamiento ha de ser muerto,
- todas las medidas adoptadas hasta el momento debe ser revertida y
- re ejecutar el trabajo J1 nuevamente

Algunas cosas que me vienen a la mente es que de todos modos debemos almacenar o mantener los estados de las aplicaciones de alguna manera, en algún lugar y luego llamar a las cosas de reversión junto con los puntos de guardado anteriores. Estaba leyendo algunos artículos sobre la reversión del nivel de base de datos, pero el escenario no encaja en este caso, ya que necesita trabajar en un entorno en tiempo real.

Pero no puedo encontrar un enfoque adecuado sobre cómo proceder y qué más debe tenerse en cuenta. Avíseme si esto no está claro, intentaré proporcionar más información si es posible.

¿Alguna ayuda o consejo?

Sistema de tiempo real o no, el patrón de recuerdo es un excelente lugar para comenzar.

El patrón de recuerdo es un patrón de diseño de software que proporciona la capacidad de restaurar un objeto a su estado anterior (deshacer mediante reversión).
El patrón de recuerdo se implementa con tres objetos: el originador, un cuidador y un recuerdo.
El originador es un objeto que tiene un estado interno.
El cuidador le hará algo al creador, pero quiere poder deshacer el cambio. El cuidador primero le pide al originador un objeto de recuerdo. Luego hace cualquier operación (o secuencia de operaciones) que iba a hacer.
Para volver al estado anterior a las operaciones, devuelve el objeto de recuerdo al originador.
El objeto de recuerdo en sí es un objeto opaco (uno que el cuidador no puede o no debe cambiar).
Al usar este patrón, se debe tener cuidado si el autor puede cambiar otros objetos o recursos: el patrón de recuerdo opera en un solo objeto.

Rompí un poco el artículo de Wikipedia para centrarme en algunos elementos.

Para su escenario, el creador será su código de aplicación principal, muy probablemente en el punto donde los trabajos se registran y comienzan a procesarse.

El cuidador es lo que necesita crear y podría ser algún tipo de sistema de registro u otro almacén de datos.

El recuerdo será la información relevante que debe deshacerse y / o rehacerse. Sospecho que esto se verá como una descripción de trabajo de algún tipo que se puede volver a colocar en la cola de procesamiento.

Si puede ajustar los cambios existentes del trabajo J1con una transacción de base de datos, eso se ocupará de sus preocupaciones de reversión ( all the action taken so far must be reverted). Cuando se produce una reversión de transacción, activaría una llamada al Caretaker para volver a poner en cola el trabajo J1.

Una cosa a tener en cuenta es esa última advertencia en el resumen de Wikipedia. Debe asegurarse de que los cambios sean atómicos y que puedan aplicarse o revertirse como un conjunto coherente.

No estoy seguro de que estar en un entorno en tiempo real tenga un gran impacto sobre cómo implementar el patrón de recuerdo. Si hay fechas límite para las actividades, es posible que deba perfilar algunos de los cambios para asegurarse de que el sistema responda en un período de tiempo adecuado. Creo que primero implementaría la funcionalidad y luego verificaría que cumple con los demás requisitos de la aplicación. No preveo que te topes con algo que invalide lo que has descrito hasta ahora.