¿Cuál es la intención del método de reversión en el patrón de unidad de trabajo?

Question

Según tengo entendido, una clase UnitOfWork pretende representar el concepto de una transacción comercial en el dominio. No se supone que represente directamente una transacción de base de datos, que es un detalle de una sola implementación posible.

Q: Entonces, ¿por qué tanta documentación sobre el patrón de Unidad de trabajo se refiere a los métodos "Confirmar" y "Revertir"?

Estos conceptos no significan nada para el dominio ni para los expertos en el dominio. Una transacción comercial puede ser "completada" y, por lo tanto, UnitOfWork debe proporcionar un método "Completo". Del mismo modo, en lugar de un método "Rollback", ¿no debería modelarse como "Clear"?

Actualización:

Respuesta: Ambas respuestas a continuación son correctos. Hay dos variantes de UoW: registro de objetos y registro de llamadas. En el registro de objetos, Rollback sirve para deshacer cambios en todos los objetos en memoria. En el registro de llamadas, la función Restaurar sirve para borrar todos los cambios registrados, de modo que la llamada subsiguiente a Confirmar no hará nada.

Answer 1

El patrón de diseño de Unidad de trabajo, al menos como lo define Fowler en Patterns of Enterprise Application Architecture - es un detalle de implementación relativo al objeto relacional asignación de persistencia. No es una entidad definida en Evans 'Domain Driven Design.

Como tal, no debe ser parte de la discusión comercial, ni una entidad que esté directamente expuesta en un modelo de dominio, quizás exceptuando el método commit(). En cambio, su intención es rastrear entidades comerciales "limpias" y "sucias": los objetos de un modelo de dominio expuesto a los clientes. El propósito es permitir múltiples interacciones, en solicitudes de contexto web, con un modelo de dominio sin la necesidad de leer y escribir desde la persistencia (generalmente una base de datos) cada vez.

Las entidades comerciales lo llaman cuando se llaman sus métodos. Cuando se altera su estado, se registran como sucios con la Unidad de Trabajo. Luego, la unidad de trabajo commit() maneja toda la transacción de persistencia en términos de escribir el gráfico de objetos y rollback() significa restaurar el estado de las entidades a lo que eran. De modo que se trata de una implementación que se filtra a la "abstracción", pero su intención es muy clara.

Por otro lado, "Deshacer" y "Completo" no necesariamente mapean uno a uno con esta definición. Un "Deshacer" o "Borrar" solo puede retrotraer un gráfico de objetos parcialmente, por ejemplo, dependiendo del contexto comercial. Si bien "Completo" bien puede estar alterando el estado en alguna entidad, así como también puede comprometer el gráfico. Como tal, pondría estos métodos, con significado comercial, en un objeto Service Layer o Aggregate Root.

Answer 2

Estoy de acuerdo. Supongo que usa los términos "Rollback" y "Commit" porque son términos conocidos (y revelan intención, especialmente para programadores). Sin embargo, creo que sería más correcto usar el término "Completo". Con respecto a "Claro", no estoy dispuesto a estar de acuerdo con usted. No creo que ningún experto en el dominio acepte que "elimine" una transacción comercial. "Deshacer" es un término más adecuado en mi opinión.