"Удаление" агрегата в DDD?

Question

[phenya]

Разбираюсь с DDD и не могу понять, кто производит действия над агрегатами. В частности, например, действие отражающие "удаление" агрегата.
Например, существует агрегат Каталог товаров (Catalog) с корневой сущностью Catalog и объектами-значениями CatalogID, Name.
Есть хранилище, используя которое можем вытащить агрегат, изменить его и сохранить обратно

$catalog = $repository->find($catalogId);
$catalog->rename('Some another name')
$repository->update($catalog);

Также в рамках другого ограниченного контекста, существуют агрегат Интеграция (Integration), с корневой сущностью Integration, объектами значениями IntegrationId, Name и коллекцией объектов значений EntityRelations. С помощью этого агрегата у нас есть возможность связать нашу любую сущность из предметной области с сущностью стороннего интегрируемого сервиса (ERP, 1C)

...
$integration->addRelation(new EntityRelation('catalog', $catalog->id(), $externalCatalogId));
$integrationRepository->update($integration);

И теперь собственно вопрос, как мне "удалить" каталог таким образом, чтобы он "удалился" вместе со всеми интеграционными связями? Очевидно, можно ввести событие "CatalogDeleted", подписаться на него и "удалять" связанные с этим каталогом интеграционные связи. Но как Catalog узнает, что он "удаляется"?

Есть идея внутри сущности Catalog объявить защищенный метод onDelete(), и в хранилище через рефлексию его дергать.

class Catalog extends AbstractEntity
{
   ...
   protected function onDelete()
   {
       $eventManager->dispatch(new CatalogDeleted($this->id()));
   }
   ...
}

class CatalogRepository extends AbstractRepository implements CatalogRepositoryInterface
{
   ...
   public function delete(Catalog $catalog)
   {
        $method = new \ReflectionMethod($catalog, 'onDelete');
        $method->setAccessible(true);
        $method->invoke($catalog);
        //дальше удаляем из БД
   }
   ...
}

Можно ли считать такой подход нормальным?

Comments

[Максим Федоров]

EntityRelation

Это не похоже на DDD, тк это точно бизнес-слой, и могу отдать руку на отсечение — такого в вашем бизнесе нет

[Максим Федоров]

Вообще же эта задача решается на уровне маппера (у вас же доктрина?)

Удаляете агрегат, а связи удаляются согласно правилам мапинга (обнуляются, удаляются)

[phenya]

Максим Федоров,

такого в вашем бизнесе нет

есть, еще как есть.

Есть каталоги товаров, они себе нормально работают, всех всё устраивает. Дальше бизнес говорит, а давайте интегрируемся с внешней ERP, чтобы можно было элементы каталогов получать напрямую из ERP, только нужно сделать сопоставление сущностей оттуда с сущностями из наших каталогов. Как это сделать? Нужно создать ограниченный контекст отдельно от нашего смыслового ядра, с каталогами, товарами и прочим. Сказано, сделано - создан ограниченный контекст с агрегатом Integration

Integration: IntegrationId, Name, EntityRelation[]
EntityRelation: IntegrationId, EntityType, InternalId, ExternalId
Пример
Integration: 'sap', 'SAP Integration', []
EntityRelation: 'sap', 'catalog', 'books', 'H13kkhj-lkj21JI'

В этом случае Catalog ничего не знает об Integration и наоборот(только на уровне метаданных). Никаких общих связей у них нет. А всё их взаимодействие происходит на уровне отдельного сервиса приложения, который занимается обменом с внешней ERP;
С другой стороны при удалении каталога (Catalog), должны удалиться и их интеграционные связи, те самые EntityRelation; Связь между разными контекстами можно реализовать с помощью событий. И это легко сделать. Но вот как Catalog узнает, что он сейчас удаляется, чтобы инициировать событие, если мы его удаляем через хранилище, которое не содержит в себе ни капли бизнес-логики и тем более не может знать, что существуют какие-то интеграции.
Возможно вместо того, что я писал выше сделать как то так:

class Catalog extends AbstractEntity
{
   private $removed = false;
   ...
   public function isRemoved()
   {
       return $this->removed;
   }

   public function remove()
   {
      $this->removed = true;
      $eventManager->dispatch(new CatalogDeleted($this->id()));
   }
   ...
}

class CatalogRepository extends AbstractRepository implements CatalogRepositoryInterface
{
   ...
   public function update(Catalog $catalog)
   {
       if($catalog->isRemoved()){
          $this->delete($catalog);
       }
   }
   
   private function delete(Catalog $catalog)
   {
       //удаляем из базы
   }
}

//Client
$catalog->remove(); //каталог всем сообщает, что он сейчас будет удален (удаляются интеграционные связи)
$repository->update($catalog); //удаляется каталог из БД

Но вот как теперь обеспечить атомарность(транзакционность) такой операции (удаление каталога + удаление интеграционных связей), учитывая, что Integration находится в другом контексте.

Answer 1

[xfg]

Идея у вас верная, только вместо защищенного onDelete, делают обычный публичный метод remove, который ничего не делает, а просто выбрасывает доменное событие. Этот метод как и все остальные просто вызывается внутри application сервиса, а затем удаляется из репозитория.

$catalog->remove();
$repository->remove($catalog);

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

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

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

Comments

[phenya]

спасибо за решение с сохранением событий и наводку на Saga Orchestration, при беглом просмотре выглядит как неплохое решение для сохранения атомарности

[xfg]

phenya, так эти доменные события изначально какой-то кривой хак. Сколько проблем они создают, вызовы какого-нибудь DomainEventService.publish(event) внутри агрегатов или создание подобного функционала на самом агрегате. Никак не меняющие состояние объекта методы типа $catalog->remove(). Вынос мозга с попытками придумать, как атомарно сохранять эти события вместе с агрегатом, учитывая, что базы бывают NoSQL где нет транзакций вообще. Потом эти события как-то нужно удалять, когда все подписчики его обработали, что тоже проблема, поскольку неизвестно вообще сколько этих подписчиков. Как-то менеджить фейловые сценарии ну и так далее. Всю эту фигню на событиях, которая получается тоже называют Saga, но Сhoreography.

У Вон Вернона в книге вот такая диаграмма.

Чего здесь только нет. Паблишеры, подписчики, хранилища, очереди, двухфазовые коммиты. Всё это развалится на боевом проекте очень быстро.

Доменные события может быть еще имеют место в event-sourcing архитектуре, но в обычной многоуровневой архитектуре от них одни проблемы.