Оптимистический механизм блокировки в потоке событий "UNDO"

Question

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

SETUP

| p_key | invoice_id | EmployeeId | Event type        | Version | Data |
|-------|------------|------------|-------------------|---------|------|
| 1     | 12345      | E456       | Invoice_Generated | 1       | JSON |
| 2     | 12345      | E567       | Invoice_Reviewed  | 2       | JSON |
| 3     | 12345      | E456       | Invoice_Paid      | 3       | JSON |
| 4     | 12345      | E142       | Invoice_Comment   | 4       | JSON |
| 5     | 12345      | E412       | Invoice_Comment   | 5       | JSON |
| 6     | 12346      | E999       | Invoice_Paid      | 7       | JSON |
| 7     | 12345      | E456       | Invoice_Refunded  | 8       | JSON |

Я предполагаю, что invoiceId является агрегатом. Поскольку номера версий будут увеличиваться при каждом изменении, внесенном в счет.

Вариант использования:

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

API CALL:

возврат / счета / {InvoiceID} / {EmployeeID}

ПОТОК ВЕЩЕЙ

Вариант 1

• Получить все события для данного счета
• Сохранить все события в потоке событий с сохранением последней версии.
• Перебрать все события, чтобы найти требуемый экземпляр события.
• Применить действие "ОТМЕНА" к этому событию и присвоить ему номер версии (последний + 1)
• позвоните в базу данных, чтобы проверить последнюю версию в хранилище событий. Проверьте, что это то же самое, что сохранено в потоке событий.
• Убедитесь, что новое событие больше последней версии в потоке. Мы предполагаем, что это также более высокая версия, которая "ДЕЙСТВУЕТ".

ВОПРОСЫ

• Получение и сохранение всех событий в приложении каждый раз может стать дорогим.
• Похоже на адскую работу "UNDO".

ВАРИАНТ 2:

• я делаю 2 звонка в базу данных
  1. Позвоните, чтобы получить событие на основе идентификатора счета-фактуры и employeeId
  2. Позвоните, чтобы получить последнюю версию последнего события, примененную к счету.
• Отменить изменения на основе данных в событии
• Создайте событие "ОТМЕНА" с версией № 1 более поздней, чем последняя.
• сделать еще один вызов в базу данных, чтобы снова получить последнюю версию.
• убедитесь, что версия "UNDO" ровно на 1 больше, чем последняя версия

ВОПРОСЫ

Не уверен, что это правильно. Должны ли мы что-то добавить в поток событий несколько раз.

Также допустимо два раза запрашивать базу данных событий только с идентификатором счета и один раз с идентификатором счета и идентификатором сотрудника

Пожалуйста, дайте мне знать, если я что-то упустил или мой стиль версии неверен, или если мое предположение о совокупности неверно.

Answer 1

Я бы посоветовал прояснить несколько моментов.

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

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

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

Если вы пытаетесь определить оптимистичные записи в реляционной базе данных, Джонатан Оливер является хорошей отправной точкой.