Избегайте шаблона работы в доменном дизайне

Ответ 1

(До моего поста я рекомендую прочитать эту главу книги В. Вернона "Внедрение доменного дизайна". Это может помочь приблизиться к агрегатам и содержать длинный ответ на ваш вопрос.)

В правильно спроектированной системе одна команда изменяет одну совокупность за раз, каждый агрегат имеет границы, которые определяются инвариантами в совокупном корне. Поэтому, когда вы делаете какие-либо изменения в совокупности, проверяются инварианты, а изменения применяются (или нет) в одной транзакции. Это последовательность транзакций. Вам нужно использовать Единицу работы здесь? Не думайте так.

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

Как уже упоминалось без контекста, трудно угадать, что думал автор, но я полагаю, что он рассказал о ситуации согласованности транзакций. В распределенной системе вам нужно будет использовать что-то вроде UoW для обеспечения возможной согласованности с системой.

Ответ 2

В принципе, согласно M. Fowler, UoW - это "просто" инструмент умного сохранения (как бы сложна эта задача). Поэтому ИМХО не существует внутренней несовместимости с подходом DDD, который дает рекомендации больше о "духе" вашего моделирования doman, чем о технических инструментах.

Без контекста трудно сказать, что думал автор цитаты; но, возможно, он написал это, потому что при использовании UoW часто бывает сложно позволить вашим сущностям управлять собственным жизненным циклом (как и другими), как правило, с сохранением и транзакционным поведением.

По сути, можно использовать шаблон UoW в приложениях с поддержкой DDD с AOP. Благодаря таким инструментам становится возможным поддерживать дух DDD, ориентированный на сущность, бизнес-модель для бизнеса, используя при этом сложные, но бизнес-ортогональные механизмы для достижения правильной последовательности транзакций.

Как правило, в мире Java вы можете использовать в своем приложении DDD:

• Hibernate/JPA как UoW: обеспечивает "умное сохранение" объектов вашей модели домена (это может быть JPA @Entity)
• Spring AOP + AspectJ: предоставляет DI в организациях
• Spring TX + AspectJ: включает транзакционные методы в ваших сущностях

Они предоставляют объекты DDD-ready (и сильно[email protected];]).