Дана послуга A (CMS), яка керує моделлю (Product, припустимо, єдині поля, які вона має, це id, назва, ціна) та послуги B (Доставка) та C (E-mail), які повинні відображати задану модель, яким повинен бути підхід синхронізувати інформацію даних моделей між цими службами у випадку підходу до пошуку подій? Припустимо, що каталог товарів рідко змінюється (але змінюється) і що є адміністратори, які дуже часто можуть отримувати доступ до даних про відправлення та електронні листи (наприклад, функціональні можливості: B: display titles of products the order containedі C display content of email about shipping that is going to be sent:). У кожної із служб є своя БД.
Рішення 1
Надсилайте всю необхідну інформацію про Продукт в рамках події - це означає наступну структуру для order_placed:
{
order_id: [guid],
product: {
id: [guid],
title: 'Foo',
price: 1000
}
}
Інформація про послуги B і C зберігається в productатрибуті JSON на ordersтаблиці
Таким чином, для відображення необхідної інформації використовуються лише дані, отримані з події
Проблеми : залежно від того, яку іншу інформацію потрібно подати в B і C, кількість даних у випадку може зростати. B і C можуть не вимагати однакової інформації про Продукт, але подія повинна містити обоє (якщо тільки ми не розділимо події на два). Якщо вказаних даних немає в межах даної події, код не може використовувати їх - якщо ми додамо параметр кольору до даного Продукту, для існуючих замовлень в B і C даний продукт буде безбарвним, якщо ми не оновлюємо події і не повторно відновлюємо їх .
Рішення 2
Надсилайте лише посібник продукту протягом події - це означає наступну структуру для order_placed:
{
order_id: [guid],
product_id: [guid]
}
Про послуги B і C інформація про продукт зберігається в product_idатрибуті ordersтаблиці
Інформацію про продукт отримують служби B і C, коли це вимагається, виконуючи виклик API до A/product/[guid]кінцевої точки
Проблеми : це робить B і C залежними від A (у всі часи). Якщо схема продукту змінюється на A, зміни повинні бути зроблені для всіх служб, що залежать від них (раптово)
Рішення 3
Надсилайте лише посібник продукту в рамках події - це означає, що структура для розміщення замовлення:
{
order_id: [guid],
product_id: [guid]
}
Про послуги B і C інформація про продукт зберігається в productsтаблиці; ще є product_idна ordersстолі, але є реплікація productsданих між A, B і C; B і C можуть містити іншу інформацію про Продукт, ніж A
Інформація про продукт A/productвиводиться під час створення служб B і C та оновлюється кожного разу, коли інформація про Продукти змінюється шляхом виклику до кінцевої точки (який відображає необхідну інформацію про всі продукти) або шляхом прямого доступу БД до А та копіювання необхідної інформації про продукт, необхідну для даної інформації сервіс.
Проблеми : це робить B і C залежними від A (при посіві). Якщо схема продукту змінюється на A, зміни потрібно внести на всі сервіси, що залежать від них (при посіві)
З мого розуміння, правильним підходом було б вирішити рішення 1 та оновити історію подій за певною логікою (якщо Каталог товарів не змінився і ми хочемо додати колір для відображення, ми можемо сміливо оновити історію, щоб отримати поточний стан продуктів і заповнити відсутні дані в рамках подій) або задовольнити відсутність даних (якщо Каталог товарів змінився і ми хочемо додати колір для відображення, ми не можемо бути впевнені, чи в той момент часу в минулому даний продукт мав колір чи ні - ми можемо припустити, що всі продукти в попередньому каталозі були чорними та задовольняли шляхом оновлення подій чи коду)
updating event historyя маю на увазі: пройти всі події, скопіювавши їх з одного потоку (v1) в інший потік (v2), щоб підтримувати послідовну схему подій.
display image at the point when purchase was made) або не може (що представляє наміри display current image as it within catalog)
updating event history- У випадку пошуку історії подій є вашим джерелом істини, і її ніколи не слід змінювати, а лише йти вперед. Якщо події змінюються, ви можете використовувати версію подій або подібні рішення, але при відтворенні подій до певного моменту стан даних має бути таким, як було в той момент.