Вполне возможно (даже вероятно), что я просто не совсем понимаю концепцию «единицы работы». По сути, я рассматриваю это как нечто вроде широкой транзакции, используемой в объектно-ориентированной среде. Запустите единицу работы, взаимодействуйте с объектами, фиксируйте или откатывайтесь. Но как это соотносится с фактическими транзакциями в хранилищах данных за этими объектами?

В системе с одной БД и ORM (например, NHibernate) это легко. Транзакция может быть поддержана через ORM. Но как насчет системы, в которой модели пользовательских доменов скрывают множество разнородных источников данных? И не все эти источники данных являются реляционными базами данных? (Здесь много сделано в файловой системе.)

Прямо сейчас я застрял в мысли, что «вы просто не можете поддерживать транзакции между БД SQL2005, БД SQL2000, БД DB2 и файловой системой в одной и той же« атомарной »бизнес-операции». Так что на данный момент разработчики в команде (которые обычно работают независимо друг от друга) несут ответственность за ведение транзакций вручную в коде. Каждая БД может иметь правильные транзакции, но бизнес-операция в целом проверяется вручную и уравновешивается на каждом значимом этапе.

Тем не менее, с ростом сложности в области и стандартной текучести разработчиков этот подход со временем будет становиться все более сложным и подверженным ошибкам.

Есть ли у кого-нибудь какие-либо советы или примеры того, как лучше всего подходить к подобному домену, или как к нему обращались раньше? Фактический «домен» в этом случае все еще находится в зачаточном состоянии, развиваясь как прототип, чтобы однажды расширить и использовать / заменить большую экосистему разрозненных унаследованных приложений. Так что есть много места для перепроектирования и ре-факторинга.

Для справки, 10 000-футовый вид дизайна, к которому я сейчас стремлюсь, таков: большая коллекция небольших по возможности глупых клиентских приложений, вызывающих центральную службу на основе сообщений. Сервис является входом в «доменное ядро» и может рассматриваться как одно большое приложение в стиле MVC. В службу направляются запросы (во многом как «действия»), которые обрабатываются обработчиками (во многом как «контроллеры»). Все процедурное идет туда. Они взаимодействуют с моделями, которые содержат все бизнес-правила. Модели публикуют события, которые слушатели («сервисы» - эта часть все еще облачна в дизайне и может быть улучшена) выбирают и обрабатывают, взаимодействуя с репозиториями (база данных x, база данных y, файловая система, электронная почта, любой внешний ресурс). Все весело-зависимо соответственно.

Извините за все многословие :) Но если у кого-нибудь есть какой-либо совет, я хотел бы услышать это. Даже (особенно), если этот совет «ваш дизайн плох, попробуйте вместо этого ...» Спасибо!