DDD / агрегированный корень / управление версиями

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

• Управление версиями как механизм управления параллелизмом для поддержки оптимистичного параллелизма
• Управление версиями как явная концепция предметной области

Управление версиями для поддержки оптимистичного параллелизма

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

Таким образом, вы оставляете управление версиями на усмотрение технологии сохраняемости, потому что цель версии - обнаруживать одновременные записи на уровень сохраняемости.

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

Управление версиями как явная концепция предметной области

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

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

• Ветвление версий
• Пользовательские имена / теги версий (но все еще связаны с «цепочкой» версий)
• Explicit version changes (user requested) vs implicit version changes (automatic on every change)
  • If I understand your intent correctly, with explicit versioning, the current 'active'/'live'/'tip' version is mutable and can be modified without tracking the change, until the user 'commits' it - it becomes immutable, and a new 'live' version that is mutable is created.

Некоторые другие концепции, которые могут возникнуть, если вы изучите эту версию:

• Слияние веток (что произойдет, если вы разделите две ветки, если вы захотите снова объединить их?)
• Откат - если у вас старая версия, поддерживаете ли вы «отмену» одного или нескольких изменений?

Учитывая вышеизложенное, вы также можете получить некоторое представление о том, как системы контроля версий работают как централизованно (например, subversion ) и распространены (например, git и mercurial), поскольку они представляют активную рабочую модель отслеживания версий со смесью изменяемых и неизменяемых элементов.

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

Как ваши пользователи / эксперты в предметной области думают о мире? Какие операции они хотят выполнять? Какова цель этих операций по отношению к их первоначальной цели? Ваша цель - сформулировать ответы на эти вопросы в модели, которая эффективно инкапсулирует процессы, с которыми они работают.

Отредактируйте, чтобы учесть моделирование

Основываясь на вашем комментарии, моим первым ответом было бы оспаривать толкование слова «версия», когда я думаю о модифицированном вопроснике. Фактически, у меня возникнет соблазн бросить вызов моделированию отношений шаблон / опрос. Рассмотрим возможный набор сущностей:

• Шаблон

  • Defines the set of questions in the questionnaire
  • Supports operations:
    • StartSurvey
    • Различные операции по изменению вопросов и параметров в шаблоне и т. Д.

• Опрос

  • Rather than referencing a 'live' template, the survey would own it's own questionnaire
  • Когда вы вызываете Template.StartSurvey, он возвращает опрос, который предварительно заполнен списком вопросов из шаблона.
  • Опрос также поддерживает изменение вопросов, но это не меняет шаблон, из которого он был создан.
  • В отличие от шаблона, опрос также поддерживает список записанных ответов и предлагает операции для установки ответов.
  • Вероятно, он также включает в себя состояние жизненного цикла, в котором в некоторых состояниях разрешается отвечать на вопросы, но после «отправки» вы не можете изменять ответы (просто догадываясь об этом).

В этом мире опрос «вытеснен» из шаблона, но затем живет самостоятельной жизнью. Вы можете изменять анкету в опросе по своему усмотрению, и это не повлияет на шаблон.

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

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