Обробка одночасності ES / CQRS

Нещодавно я почав занурюватися в CQRS / ES, тому що мені може знадобитися застосувати це на роботі. Це здається дуже перспективним у нашому випадку, оскільки це вирішило б багато проблем.

Я накреслив своє грубе розуміння того, як додаток ES / CQRS повинен виглядати контекстуально під спрощений випадок використання банківських операцій (зняття грошей).

Просто підводячи підсумки, якщо людина A знімає гроші:

• команда видається
• команда передається для перевірки / перевірки
• подія висувається в магазин подій, якщо перевірка успішна
• агрегатор відмовляється від події застосувати зміни до сукупності

З того, що я зрозумів, журнал подій є джерелом істини, оскільки це журнал ФАКТІВ, ми можемо вивести з нього будь-яку проекцію.

Тепер, що я не розумію, в цій грандіозній схемі речей, що відбувається в цьому випадку:

• правило: баланс не може бути негативним
• людина A має баланс 100e
• особа A видає ВиведенняCommand 100e
• перевірка валідації та випромінюється подія MoneyWithdrewEvent of 100e
• тим часом, людина A видає ще один WithdrawCommand 100e
• перший MoneyWithdrewEvent ще не зведений, тому перевірка проходить, тому що перевірка перевірки сукупності (що ще не оновлено)
• MoneyWithdrewEvent з 100e випромінюється в інший раз

==> Ми знаходимось у несуперечливому стані балансу на рівні -100e, а журнал містить 2 MoneyWithdrewEvent

Як я розумію, існує декілька стратегій для вирішення цієї проблеми:

• а) помістіть сукупний ідентифікатор версії разом із подією в сховище, так що якщо при модифікації є невідповідність версії, нічого не відбувається
• б) використовувати деякі стратегії блокування, маючи на увазі, що шар перевірки повинен якось створити його

Питання, що стосуються стратегій:

• а) У цьому випадку журнал подій вже не є джерелом істини, як з цим боротися? Крім того, ми повернулися до клієнта ОК, тоді як дозволити відкликання було абсолютно неправильно, чи краще в цьому випадку користуватися замками?
• б) Замки == тупики, чи маєте ви уявлення про кращі практики?

Загалом, чи правильно я розумію, як поводитися з одночасністю?

Зауважте: я розумію, що та сама людина вилучає двічі гроші за такий короткий проміжок часу, що неможливо, але я взяла простий приклад, щоб не загубитися в деталі

Я накреслив своє грубе розуміння того, як додаток ES / CQRS повинен виглядати контекстуально під спрощений випадок використання банківських операцій (зняття грошей).

Це ідеальний приклад програми, що спричиняє події. Давайте розпочнемо.

Кожен раз, коли команда обробляється або повторюється (ви зрозумієте, будьте терплячі) виконуються наступні дії:

1. команда досягає обробника команд, тобто служби в Application layer.
2. обробник команд ідентифікує Aggregateі завантажує його з репозиторію (у цьому випадку завантаження виконується шляхом new-ing Aggregateекземпляра, отримання всіх раніше випромінюваних подій цього агрегату та повторного застосування їх до самого агрегату; версія агрегату зберігається для пізніше використання; після застосування подій сукупність знаходиться в остаточному стані - тобто залишок поточного рахунку обчислюється як число)
3. обробник команд викликає відповідний метод на Aggregate, як, Account::withdrawMoney(100)і збирає вихідні події, тобто MoneyWithdrewEvent(AccountId, 100); якщо на рахунку не вистачає грошей (залишок <100), тоді підвищується Виняток і все припиняється; в іншому випадку виконується наступний крок.
4. обробник команд намагається зберігати Aggregateдо сховища (у цьому випадку сховище - це Event Store); це роблять, додаючи нові події до Event streamif і тільки якщо the versionof Aggregateвсе ще є тим, що було коли Aggregateбуло завантажено. Якщо версія неоднакова , то команда повторюється - перейдіть до кроку 1 . Якщо значення versionзбігається, події додаються до Event streamі клієнту надається Successстатус.

Ця перевірка версій називається оптимістичним блокуванням і є загальним механізмом блокування. Ще один механізм - це песимістичне блокування, коли інші записи блокуються (як і в не запущені) до завершення поточного.

Термін Event stream- це абстракція навколо всіх подій, які випромінював той самий агрегат.

Ви повинні розуміти, що Event storeце просто інший вид наполегливості, де зберігаються всі зміни сукупності, а не лише остаточний стан.

а) У цьому випадку журнал подій вже не є джерелом істини, як з цим боротися? Крім того, ми повернулися до клієнта ОК, тоді як дозволити відкликання було абсолютно неправильно, чи краще в цьому випадку користуватися замками?

Магазин подій завжди є джерелом істини.

б) Замки == тупики, чи маєте ви уявлення про кращі практики?

За допомогою оптимістичного блокування у вас немає блокувань, просто повторіть команду.

У будь-якому разі, Замки! = Тупики

Я накреслив своє грубе розуміння того, як додаток ES / CQRS повинен виглядати контекстуально під спрощений випадок використання банківських операцій (зняття грошей).

Закрити. Проблема полягає в тому, що логіка оновлення вашого "сукупності" знаходиться в дивному місці.

Більш звичною реалізацією є те, що модель даних, яку ваш обробник команд зберігає в пам'яті, і потік подій у сховищі зберігаються синхронізовано.

Простий приклад для опису - це випадок, коли обробник команд робить синхронні записи в сховище подій та оновлює свою локальну копію моделі, якщо підключення до сховища даних вказує на те, що запис вдалося.

Якщо обробнику команд необхідно повторно синхронізуватись із сховищем подій (оскільки його внутрішня модель не відповідає тій, що зберігається), це зробить, завантаживши історію з магазину та відновивши власний внутрішній стан.

Іншими словами, стрілки 2 і 3 (якщо вони є) зазвичай були б з'єднані з магазином подій, а не з сукупним сховищем.

покладіть сукупний ідентифікатор версії разом із подією в магазин подій, так що якщо при модифікації є невідповідність версії, нічого не відбувається

Варіації цього є звичайним випадком - замість того, щоб додавати до потоку в потоці подій, ми зазвичай PUT до певного місця в потоці; якщо ця операція несумісна зі станом магазину, запис припиняється, і сервіс може обрати відповідний режим відмови (відмовитись від клієнта, повторити, об'єднати ....). Використання idempotent write вирішує низку проблем при розподілі повідомлень, але, звичайно, потрібно мати магазин, який підтримує idempotent write.