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