Проектирование на основе домена: массовые действия с агрегатами (импорт, массовое редактирование и т. Д.) - PullRequest
0 голосов
/ 28 августа 2018

В определенные моменты в моем приложении будет гораздо удобнее предоставлять пользователю функции массовых действий для повышения удобства использования. Некоторые сценарии, с которыми мы сталкиваемся:

Сценарий 1: Массовое создание совокупности, состоящей из совокупного корня и n числа дочерних объектов (одного и того же экземпляра) посредством импорта. Импорт должен полностью завершиться успешно или завершиться неудачей в противном случае.

Сценарий 2: Массовое действие / редактирование выбора агрегатов или создание другого агрегата из набора «исходных» агрегатов и т. Д. Через пользовательский интерфейс. Массовое действие должно полностью завершиться или завершиться неудачей в противном случае.

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

Сценарий 1:

  1. CreateAggregateRootCommand
  2. FindAggregateRootQuery
  3. AddChildEntityCommmand
  4. AddChildEntityCommand
  5. AddChildEntityCommand и т. Д.

Сценарий 2:

  1. PlaceNewOrderCommand
  2. FindOrderQuery
  3. AddProductToOrderCommand
  4. AddProductToOrderCommand
  5. AddProductToOrderCommand

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

У кого-нибудь есть опыт выполнения подобных массовых действий? Я знаю, что это переход на территорию реализации, но эти действия являются частью UL, и я не видел там много такого, что бы указывало на лучшую архитектуру и подход к проектированию.

Некоторые мысли:

Сценарий 1:

  • Файл может быть передан на уровень обслуживания приложений.

Тогда:

  • Эта служба приложений может затем использовать FileParsingService (служба инфраструктуры?) Для создания агрегатов из данных импорта.

  • Парсер, похоже, выполняет двойную задачу: анализ данных и создание объектов.

Или:

  • Служба приложений может использовать FileParsingService, который создаст пакет команд, указанных выше, инкапсулированных в BatchCommand, т. Е.

    Класс BatchCreateAggregate CreateAggregateRootCommand createAggregateCommand коллекция addChildEntityCommands

Затем они будут обрабатываться BatchCreateAggregateHandler, который атомарно создаст всю совокупность.

Альтернатива:

  • Синтаксический анализ файла происходит на уровне презентации, и BatchCommand отправляется на прикладной уровень.

Сценарий 2:

  • Аналогично выше. Пользователь выбирает несколько продуктов, а затем

  • Создание команды BatchPlaceNewOrderCommand, состоящей из команды PlaceNewOrderCommand и набора команд AddProductToOrderCommands

  • Отправьте их BatchPlaceNewOrderHandler.

Являются ли эти подходы действительными? Мне известно, что несколько сущностей обновляются одновременно одной командой, но, по крайней мере, это один и тот же совокупный корень.

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

Спасибо

...