DDD — сохраняющиеся совокупные дочерние элементы, только если изменены
Я пытаюсь использовать DDD в приложении, над которым я сейчас работаю.
У меня есть следующая структура UserAggregate:
UserAggregate
- ProfileEntity
- ImageEntity
- RatingEntity
И у меня есть UserRepository, который запрашивает сопоставления сущностей для создания UserAggregate.
Теперь я хотел бы передать UserAggregate в UserRepository для сохранения, как UserRepository->save(UserAggregate), Как сообщить UserRepository, что дочерние объекты UserAggregate изменились и должны быть сохранены? Есть ли какой-то общий шаблон для этого? Я знаю шаблон UintOfWork, но не могу себе представить, как он может помочь детям, так как Я хотел бы поразить мапперы (и базу данных), только если дочерние сущности действительно изменены.
Есть ли способ отследить «грязное состояние» объекта-сущности, особенно в PHP? Или я пропустил понятие совокупных корней и репозиториев?
Решение
Есть в основном два подхода к этой проблеме. Вы можете использовать сравнение снимков или же отслеживание изменений на основе прокси. Оба из них имеют свои преимущества и недостатки. Выбор также зависит от библиотек, которые вы используете, поскольку они могут поддерживать одну из них.
Здесь я опишу основные подходы. Я не знаю, какие именно библиотеки вы используете, так что это поможет вам выбрать стратегию и оценить библиотеки.
Основные вопросы дизайна
Обе стратегии являются ответственностью механизма постоянства и НЕ ДОЛЖНЫ просачиваться в область и логику приложения. Другими словами, они должны быть прозрачными для пользователей репозитория и объектов домена.
Сравнение снимков
С помощью этой стратегии вы сохраняете моментальный снимок агрегированных данных, когда агрегат загружается через репозиторий. Позже, когда потенциально модифицированный агрегат передается в Update вызовите хранилище еще раз, вы пройдете по агрегату, чтобы определить, изменились ли данные в нем или нет.
Отслеживание изменений на основе прокси
С помощью этой стратегии вы возвращаете объект, который проксирует реальный агрегат, а не сам агрегат. Прокси создается и используется для переноса агрегата, когда агрегат загружается через репозиторий.
Прокси-сервер ничего не делает для операций чтения в агрегате, но устанавливает грязный флаг всякий раз, когда вызывается мутирующая операция. Когда (прокси) агрегат передается в хранилище для сохранения, вы просто проверяете грязный флаг.
Другие решения
Других решений пока нет …