Я читаю про пошук подій і маю питання щодо наполегливості.
Я все ще можу мати БД з усіма сутностями, правда? Або події повинні відтворюватися щоразу, коли програма починає отримувати останню версію кожної сутності у пам'яті? Здається, що це трата на більші системи (як у великій кількості даних)?
Справа в пошуку подій полягає в тому, що я можу повторити події, щоб заповнити сховище даних, якщо потрібно? (або проаналізувати дані)
Відповіді:
Ви отримаєте найбільшу користь від пошуку подій, коли також вирішите змінити архітектуру системи. Якщо піти в напрямку архітектури стилю CQRS у поєднанні з DDD, ви зможете принести справжні переваги пошуку подій, принаймні, на мою думку.
Побудувати магазин подій, який добре поводиться у великих системах, справді непросте завдання. Відтворення всіх даних дійсно може бути дорогим, багато що залежить від кількості даних, які потрібно відтворити. Але є методи, які можуть допомогти вам у цьому, одна з них - концепція знімка. Повтор проводиться лише з певного моменту вперед. Переваги, які приносить магазин подій у вашу систему, є неоціненними. Отримавши все, що трапилось у вашій системі, можливість повторного перегляду всіх даних - це чудова річ. Подумайте про аналіз, про відтворення помилок, про статистику.
Існує багато чудових магазинів подій, останній щойно був випущений вчора Event Store, і це здається справді хорошим.
Традиційну базу даних можна зберігати для запитної частини вашої системи для складання DTO із запитуваними даними. Цю базу даних можна організувати та оптимізувати, враховуючи потреби запиту вашої програми та клієнтів.
Я написав докладну статтю про те, які переваги та як насправді виглядає архітектура CQRS у поєднанні з джерелом подій. Ви можете перевірити це на CQRS, події в домені та DDD .
Основне питання "Події Sourcing" - "яка ваша книга записів".
Якщо ваша книга записів - ваш потік подій, то у вас не буде проблем. Якщо ваша книга записів є вашою "моделлю сутності", то проблеми почнуть виникати всюди. Частина цього полягає в тому, що ви можете сказати, "якби я втратив модель сутності, я міг би відновити її зі свого потоку подій". Якщо ви позитивно ставитесь до цього питання, то ваш Журнал подій - це ваша книга рекордів.
Також важливо пам’ятати, що більшість людей, які використовують джерела подій, використовують зчитувану модель. Ця модель використовується для запиту даних. Це швидше виглядатиме на зразок моделі 1nf, ніж 3nf модель сутності. Вони лише відтворюють події для повернення станів сукупностей, щоб визначити, чи слід дозволяти записувати.
Я все ще можу мати БД з усіма сутностями, правда? Або події повинні відтворюватися щоразу, коли програма починає отримувати останню версію кожної сутності у пам'яті?
Відповідь залежить від вимог вашої програми. Я бачив, що це робиться обома способами.
Один надзвичайно вдалий програмний пакет для невеликих бухгалтерських фірм читає свій журнал CQRS щоразу при запуску. Необхідна кількість даних була відносно невеликою, тому час запуску був менше хвилини навіть на повільних комп'ютерах. Вони роблять CQRS більше десяти років, перш ніж практика стала популярною. Вони знали, що вони переживають щось хороше, коли зрозуміли, що можуть оновити дані своїх клієнтів знову і знову, не стикаючись з проблемами, які виникають у великих системах.
У системах з більшими обсягами даних та / або системах, які покладаються на функціональність RDBMS для реалізації сторони запиту, у вас є база даних для "поточного перегляду" даних, породжених подіями (у вас навіть може бути кілька таких переглядів). Перевага такого підходу полягає в тому, що він дозволяє будувати сторону запиту, використовуючи звичні технології.