DDD: шаблон для подачи и утверждения контрактов

Я работаю над приложением, в котором существуют следующие требования:

  • Пользователь отправляет некоторые данные в форме, и они сохраняются как "Черновик".
  • С другой стороны, утверждающий читает его и предпринимает некоторые действия (одобрить, отклонить и т. Д.)
  • Если утверждающий утверждает черновик, он становится контрактом, и обе стороны юридически связаны. Исходный отправитель может вернуться, внести изменения в черновик и повторно отправить его. Когда утверждающий утверждает самую последнюю версию, существующий контракт заменяется новым.

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

Это не проблема управления документами. Всегда существует ровно одна Черновая копия, с которой работает отправитель, и иногда существует Контракт, который не может редактировать ни одна из сторон (изменения выполняются путем повторной отправки Черновой копии с изменениями). Для этих целей поля в этих двух концепциях домена идентичны.

Есть ли какой-то шаблон дизайна или DDD дружественное решение, которое можно применить здесь?

1 ответ

Решение

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

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

И Грег Янг:

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

Грег Янг

Когда пользователь отправляет "Черновик", он должен вызвать событие и сохранить его в EventSourcing, Другой пользователь поднять еще один "черновик" будет захвачен EventSourcing объект и пометить его как новую версию. Как сделать это по-другому, вы должны применить DDD. Объект документа является Domain объект и есть идентификатор.

Это будет легко для запроса и обновления состояния из Eventsourcing для каждой версии объекта и верните версию объекта.

Вы можете взять больше упоминаний о EventSourcing из MSDN.

Надеюсь, это поможет.

Другие вопросы по тегам