É possível (até provável) que eu simplesmente não esteja totalmente grunhindo o conceito de "unidade de trabalho". Basicamente, eu vejo isso como uma espécie de transação ampla usada em um ambiente orientado a objetos. Iniciar a unidade de trabalho, interagir com os objetos, confirmar ou retroceder. Mas como isso se decompõe nas transações reais nos armazenamentos de dados por trás desses objetos?

Em um sistema com um único banco de dados e um ORM (como o NHibernate), é fácil. A transação pode ser mantida através do ORM. Mas e quanto a um sistema em que os modelos de domínio personalizados estão obscurecendo muitas fontes de dados diferentes? E nem todas essas fontes de dados são bancos de dados relacionais? (Há muito o que fazer no sistema de arquivos por aqui.)

No momento, estou preso à ideia de que "você simplesmente não pode manter uma transação entre um banco de dados SQL2005, um banco de dados SQL2000, um banco de dados DB2 e o sistema de arquivos na mesma operação comercial" atômica "." Por enquanto, é de responsabilidade dos desenvolvedores da equipe (que geralmente trabalham independentemente um do outro) manter as transações manualmente no código. Cada banco de dados pode ter transações apropriadas, mas a operação de negócios como um todo é manualmente verificada e equilibrada a cada passo significativo do caminho.

No entanto, com a crescente complexidade no domínio e a rotatividade padrão de desenvolvedores, essa abordagem se tornará cada vez mais difícil e propensa a erros ao longo do tempo.

Alguém tem algum conselho ou exemplo de como um domínio como esse pode ser melhor tratado ou como já foi abordado antes? O "domínio" real, neste caso, ainda está em sua infância, evoluindo como um protótipo para um dia expandir e consumir / substituir um grande ecossistema de aplicativos herdados díspares. Portanto, há muito espaço para re-projetar e re-fatorar.

Para referência, uma visão de 10.000 pés do design que pretendo atualmente é: Uma grande coleção de aplicativos clientes tão burros quanto possível, chamando um serviço central de mensagens. O serviço é a porta de entrada para o "núcleo do domínio" e pode ser pensado como um grande aplicativo no estilo MVC. As solicitações são feitas ao serviço (como "ações"), que são atendidas pelos manipuladores (como "controladores"). Qualquer coisa processual vai para lá. Eles interagem com os modelos, que contêm todas as regras de negócios. Os modelos publicam eventos que os ouvintes ("serviços" - esta parte ainda está turva no design e estão sujeitos a aprimoramentos) captam e manipulam interagindo com repositórios (banco de dados x, banco de dados y, sistema de arquivos, email, qualquer recurso externo). Todos alegremente injetados em dependência de acordo.

Desculpe por toda a verbosidade :) Mas se alguém tiver algum conselho, eu adoraria ouvi-lo. Mesmo (especialmente) se esse conselho for "seu design é ruim, tente fazer isso ..." Obrigado!