#domain-driven-design #unit-of-work
Вопрос:
А именно, если совокупный корень является границей транзакции и если каждая AR имеет свой репозиторий, какой смысл использовать UnitOfWork и группировать различные операции с репозиториями в одну транзакцию?
Разве это на самом деле не противоречит основам DDD, где AR является границей транзакции?
Я просто не могу примирить эти два.
Ответ №1:
«Меняйте по одному агрегату за раз» — это предложение, которому следует внимательно следовать, но это не строгое правило, которое никогда нельзя нарушить. Могут возникнуть ситуации, когда просто имеет смысл его нарушить, в зависимости от того, какой у вас домен.
Но имейте в виду, что вам также не нужен UoW в этом сценарии. Это инфраструктура, детали реализации. Можете использовать или не использовать его, это не повлияет на применяемый вами дизайн DDD и не сделает его недействительным.
Кроме того, UoW полезны не только для того, чтобы управлять более чем одним AR одновременно. Вы можете использовать их для создания репозитория, который ведет себя как постоянные коллекции в памяти. (т. е. репозиторий, в котором есть add remove find методы,,, но не требуется save или persist ). UoW может отслеживать изменения и удалять транзакцию позже.
Комментарии:
1. разве это не сделало бы недействительным дизайн ddd, если бы он полагался на транзакционность, застрахованную инфраструктурой, в отличие от той, которая застрахована дизайном/границами AR? PS. я пишу в контексте 7 из 10 примеров использования ddd единицы работы, которые могут заставить кого-то подумать, что это правильный путь, а не исключительный инструмент для использования.