Es posible (incluso probable) que simplemente no esté asimilando completamente el concepto de una "unidad de trabajo". Básicamente, lo veo como una especie de transacción amplia utilizada en un entorno orientado a objetos. Comience la unidad de trabajo, interactúe con los objetos, comprométase o retroceda. Pero, ¿cómo se descompone esto en las transacciones reales en los almacenes de datos detrás de esos objetos?

En un sistema con un solo DB y un ORM (como NHibernate) es fácil. La transacción se puede mantener a través del ORM. Pero, ¿qué pasa con un sistema donde los modelos de dominio personalizados están ocultando muchas fuentes de datos dispares? ¿Y no todas esas fuentes de datos son bases de datos relacionales? (Aquí se hace mucho en el sistema de archivos).

En este momento estoy atascado en la idea de que "simplemente no se puede mantener una transacción en una base de datos SQL2005, una base de datos SQL2000, una base de datos DB2 y el sistema de archivos en la misma operación comercial 'atómica'". Entonces, por ahora, es responsabilidad de los desarrolladores del equipo (que generalmente trabajan independientemente el uno del otro) mantener las transacciones manualmente en el código. Cada base de datos puede tener transacciones adecuadas, pero la operación comercial en su conjunto se verifica y equilibra manualmente en cada paso significativo del camino.

Sin embargo, con la creciente complejidad en el dominio y la rotación estándar de desarrolladores, este enfoque será cada vez más difícil y propenso a errores con el tiempo.

¿Alguien tiene algún consejo o ejemplo de cómo un dominio como este podría abordarse mejor, o cómo se ha abordado antes? El "dominio" real en este caso todavía está en su infancia, evolucionando como un prototipo para expandir un día y consumir / reemplazar un gran ecosistema de aplicaciones heredadas dispares. Por lo tanto, hay mucho espacio para rediseñar y refactorizar.

Como referencia, una vista de 10,000 pies del diseño que estoy buscando actualmente es: Una gran colección de pequeñas aplicaciones de cliente tan tontas como sea posible que llaman a un servicio central basado en mensajes. El servicio es la entrada al "núcleo de dominio" y puede considerarse como una gran aplicación de estilo MVC. Las solicitudes se hacen al servicio (al igual que las "acciones") que son recogidas por los controladores (al igual que los "controladores"). Todo lo procesal va allí. Interactúan con los modelos, que contienen todas las reglas de negocio. Los modelos publican eventos que los oyentes ("servicios", esta parte aún está turbia en el diseño y sujeto a mejoras), retoman y manejan interactuando con repositorios (base de datos x, base de datos y, sistema de archivos, correo electrónico, cualquier recurso externo). Todos felizmente inyectados de dependencia en consecuencia.

Perdón por toda la verbosidad :) Pero si alguien tiene algún consejo, me encantaría escucharlo. Incluso (especialmente) si ese consejo es "su diseño es malo, intente esto en su lugar ..." ¡Gracias!