DDD: Сохранение агрегируется
Давайте рассмотрим типичный пример Порядка и OrderItem. Предполагая, что OrderItem является частью Агрегата Порядка, это единственное быть добавленным через Порядок. Так, для добавления нового OrderItem к Порядку мы должны загрузить весь Агрегат через Репозиторий, добавить, что новый объект к Порядку возражает и сохраняет весь Агрегат снова.
Это, кажется, имеет много издержек. Что, если наш Порядок имеет 10 OrderItems? Таким образом, только для добавления нового OrderItem, мало того, что мы должны считать 10 OrderItems, но и мы должны также повторно ввести все эти 10 OrderItems снова. (Это - подход, который Jimmy Nillson проявил в своей книге DDD. Каждый раз он хочет, сохраняет Агрегат, он очищает все дочерние объекты и затем повторно вставляет их снова. Это может вызвать другие проблемы, поскольку идентификатор детей изменяется каждый раз из-за столбца IDENTITY в базе данных.)
Я знаю, что некоторые люди могут предложить применить шаблон Единицы работы в Совокупном Корне, таким образом, он отслеживает то, что было изменено и только фиксирует те изменения. Но это нарушает принцип Незнания персистентности (PI), потому что логика персистентности просачивается в Модель предметной области.
Кто-либо думал об этом прежде?
Mosh
2 ответа
Весь агрегат должен быть загружен из базы данных, поскольку DDD предполагает, что агрегированные корни обеспечивают согласованность в пределах границ агрегатов. Чтобы эти правила были соблюдены, все необходимые данные должны быть загружены. Если существует требование, чтобы стоимость заказа для конкретного клиента не превышала 100000 долларов США, совокупный корень (Заказ) должен проверить это правило перед сохранением изменений. Это не означает, что все существующие элементы должны быть загружены и их стоимость суммирована. Заказ может поддерживать предварительно рассчитанную сумму существующих позиций, которая обновляется при добавлении новых. Таким образом, проверка бизнес-правила требует, чтобы при добавлении новых элементов загружались только данные заказа.
Это не обязательно должно быть проблемой, некоторые ORM поддерживают ленивые списки. Например. Вы можете загрузить сущность order и добавить элементы в коллекцию Details без фактической материализации всех остальных сущностей в этом списке.
Я думаю, что N/Hibernate поддерживает это.
Если вы пишете свой собственный код персистенции сущностей без ORM, то вам практически не повезло, вам придется заново реализовывать тот же самый механизм отслеживания, который ORMappers предоставляет вам бесплатно.