DDD — как обрабатывать одну транзакцию в нескольких ограниченных контекстах при сохранении на многоцелевой странице пользовательского интерфейса

DDD — как обрабатывать одну транзакцию в нескольких ограниченных контекстах при сохранении на многоцелевой странице пользовательского интерфейса
DDD — как обрабатывать одну транзакцию в нескольких ограниченных контекстах при сохранении на многоцелевой странице пользовательского интерфейса - wenhao_ryan @ Unsplash

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

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

Конечно, операция сохранения внутри вашего пользовательского интерфейса должна

  • перебирать все три частичных сохранения

  • собирать состояние отказа и сообщения об отказе для каждого отдельного шага,

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

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

Есть несколько вариантов, которые можно рассмотреть, чтобы сделать это более удобным для пользователя:

  • Вы можете визуализировать, какие параметры / атрибуты уже сохранены в БД, а какие ожидают сохранения. В зависимости от приложения и способа его использования, это может быть незначительным, или решающим, или просто удобным.

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

Наконец, если вам действительно нужно реализовать транзакцию для нескольких ограниченных контекстов, которые могут храниться в разных системах хранения, обратите внимание на такие методы, как двухфазный коммит или шаблон Saga . Здесь также есть Stackoverflow Q&A, где сравниваются эти два метода.


LetsCodeIt, 19 января 2023 г., 05:59