DDD: сохраняющиеся агрегаты

Question

Рассмотрим типичный пример Order и OrderItem . Предполагая, что OrderItem является частью Order Aggregate, он может быть добавлен только через Order. Итак, чтобы добавить новый OrderItem в Order, нам нужно загрузить весь Aggregate через репозиторий, добавить новый элемент в объект Order и сохранить Весь Агрегат снова.

Кажется, это накладные расходы. Что если наш Order имеет 10 OrderItems ? Таким образом, просто чтобы добавить новый OrderItem , мы не только должны прочитать 10 OrderItems , но мы также должны заново вставить все эти 10 OrderItems снова , (Это подход, который Джимми Нилсон использовал в своей книге DDD. Каждый раз, когда он хочет сохранить Агрегат, он очищает все дочерние объекты, а затем повторно вставляет их снова. Это может вызвать другие проблемы, так как идентификаторы детей меняется каждый раз из-за столбца IDENTITY в базе данных.)

Я знаю, что некоторые люди могут предложить применить шаблон «Единица работы» в Агрегированном корне, чтобы он отслеживал то, что было изменено, и фиксировал только эти изменения. Но это нарушает принцип постоянного невежества (PI), поскольку логика постоянства просачивается в модель предметной области.

Кто-нибудь думал об этом раньше?

Мош

Answer 1

Весь агрегат должен быть загружен из базы данных, поскольку DDD предполагает, что агрегатные корни обеспечивают согласованность в границах агрегатов. Чтобы эти правила были проверены, все необходимые данные должны быть загружены. Если существует требование, что заказ может стоить не более 100000 долларов США для конкретного клиента, совокупный корень (Заказ) должен проверить это правило перед сохранением изменений. Это не означает, что все существующие элементы должны быть загружены, а их стоимость суммирована. Заказ может поддерживать предварительно рассчитанную сумму существующих элементов, которая обновляется при добавлении новых. Этот способ проверки бизнес-правила требует загрузки только данных заказа при добавлении новых позиций.

Answer 2

Я не уверен на 100% в этом подходе, но я думаю, что применение шаблона работы может быть ответом. Помня о том, что любая транзакция должна выполняться в службах приложений или доменов, вы можете заполнить единицу рабочего класса / объекта объектами из агрегата, который вы изменили. После этого позвольте классу / объекту UoW творить чудеса (в некоторых случаях создание правильного UoW может быть затруднено)

Здесь приведено описание единицы работы с здесь :

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

Answer 3

Это не должно быть проблемой, некоторые ленивые списки поддержки ORM. например Вы можете загрузить сущность заказа и добавить элементы в коллекцию Details без фактической материализации всех других сущностей в этом списке.

Я думаю, что N / Hibernate поддерживает это.

Если вы пишете свой собственный код персистентности сущности без какого-либо ORM, то вам в значительной степени не повезло, вам придется заново внедрить тот же механизм грязного отслеживания, который ORMappers предоставляет вам бесплатно.