Транзакции, пересекающие совокупные границы

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

Есть два типа работы JobA, JobB. JobA состоит из задач TaskA. JobB состоит из задач TaskB. JobA и JobB не связаны. Единственное, что их объединяет, это то, что им обоим нужен ресурс оборудования. Изначально я хотел создать 5 совокупных корней, которые могут ссылаться друг на друга - JobA будет ссылаться на TaskA и так далее.

Модель домена

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

  1. Работа не может быть помечена как завершенная, если какая-либо задача еще не завершена. Эта проверка заставляет транзакции пересекать границы агрегатов (например, TaskA и JobA).
  2. Оборудование не может быть назначено более чем на 1 работу. Эта проверка будет охватывать оба агрегата заданий.
  3. Оборудование должно быть выпущено до того, как работа будет отмечена как завершенная. Эта транзакция будет пересекать агрегаты оборудования и работы.

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


transactions domain-driven-design aggregateroot domain-model
person 341008    schedule 04.07.2015    source источник
comment
Некоторые правила невозможно сделать строго последовательными на практике, и в конечном итоге их придется сделать последовательными.   -  person plalx    schedule 06.07.2015

Ответы (2)


arrow_upward
1
arrow_downward

Я думаю, что лучшим решением может быть конечная согласованность.

Когда у меня возникают сомнения по поводу разработки соглашений, я всегда обращаю внимание на эффективный дизайн агрегата от Вона Вернона.

person Josué Pech    schedule 09.07.2015
comment
Я тоже этим пользовался :). Но найти решение оттуда не удалось. Может, я что-то упускаю. Я думал о возможной последовательности, но проблема в том, что человеку не разрешается переходить на новую работу, пока он не закончит текущую. И задание является частью рабочего процесса, поэтому все задачи должны быть завершенными, когда они помечены как завершенные - не могут допустить, чтобы они не синхронизировались в любой момент. - person 341008; 12.07.2015
comment
Я думаю, вы ничего не упускаете. Я думаю, что это будет зависеть от перспективы бизнеса, допустят ли они, чтобы задания не синхронизировались в течение небольшого промежутка времени или нет. - person Josué Pech; 13.07.2015
comment
@ 341008 интересно, что вы в итоге здесь делаете и почему. У меня эта ситуация пошла обоими путями. - person Jordan; 27.06.2019

arrow_upward
0
arrow_downward

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

  1. У вакансии должен быть список задач с их статусами. Когда задача завершается в своей собственной транзакции, она отправляет событие / сообщение TaskCompleted, а затем Job забирает его и обновляет статус задачи внутри. Таким образом, Job знает, все ли задачи выполнены, не проверяя агрегирование задач.

  2. Привязка оборудования к работе должна выполняться по агрегату «Оборудование». Это сгенерирует событие / сообщение EquipmentAssignedToJob, которое будет использоваться агрегатом Job для обновления своего состояния с информацией о том, что это задание использует это оборудование. Оборудование будет знать свое состояние, используется оно или нет.

  3. Действие завершения задания освободит Оборудование. При освобождении оборудования от задания генерируется событие / сообщение JobFinishedUsingEquipment, которое может быть использовано оборудованием, и состояние оборудования будет обновлено до неиспользованного.

person Vladas Cibulskis    schedule 08.12.2016