Перевод статьи был подготовлен до начала курса.
Профессионал» .
Поиск событий (источник событий, регистрация событий, генерация событий) — это мощный архитектурный шаблон, в котором все изменения, внесенные в состояние приложения, сохраняются в той последовательности, в которой они произошли.
Эти записи служат одновременно источником текущего состояния и журналом аудита того, что происходило в приложении за время его существования.
Источник событий способствует децентрализованному изменению и чтению данных.
Эта архитектура хорошо масштабируется и подходит для систем, которые уже работают с обработкой событий или хотят перейти на такую архитектуру.
Что такое источник событий
Эксперты в предметной области обычно описывают свои системы как набор сущности , которые являются контейнерами для хранения состояния и события , отражающие изменения сущностей в результате обработки входных данных в рамках различных бизнес-процессов.Часто события запускаются команды исходящие от пользователей, фоновых процессов или интеграции с внешними системами.
По сути, поиск событий фокусируется на события связанных с изменениями в системе.
Многие архитектурные шаблоны рассматривают сущности как основную концепцию.
Эти шаблоны описывают, как их хранить, как получать к ним доступ и как их изменять.
В рамках этого архитектурного стиля события часто бывают «побочными»: они являются последствиями изменения сущностей.
Обычно такие архитектуры основаны на хранилище сущностей, например реляционной базе данных или хранилище документов.
Хотя события могут присутствовать в такой архитектуре, они по своей сути не являются основной концепцией и могут быть отделены от сущностей, с которыми они связаны, а также скрыты за уровнями бизнес-логики.
Event Sourcing меняет этот подход, фокусируясь на реализации событий: как они хранятся и как их можно использовать для получения состояния объекта.
В этом случае база данных будет содержать последовательный журнал всех событий, произошедших за время существования системы.
Ниже приведено сравнение хранилища событий с хранилищем сущностей (более подробно описано ниже): 
Источник событий, использующий события в качестве основной архитектурной концепции, также является парадигмой моделирования предметной области, которая лучше отражает взгляд клиента на систему.
Проектирование систем с акцентом на события и журналы событий дает следующие преимущества: Помогает уменьшить несоответствие импедансов и необходимость составления концептуальных карт, позволяя технологическим командам «говорить на одном языке» с бизнесом при обсуждении системы.
Поощряет разделение обязанностей на команды и просьбы ( ответственность за команду/запрос ), позволяющий оптимизировать письмо и чтение независимо друг от друга.
Разумеется, обеспечивает временность и историю изменений, позволяя ответить на вопросы о том, как система выглядела в определенные моменты в прошлом и какие события происходили до этого момента.
Как работает источник событий
Давайте рассмотрим простой пример с банковским счетом.Мы будем иметь сущность , который является банковским счетом.
Для простоты мы создадим только одну учетную запись, не идентифицируя ее по номеру счета или каким-либо другим способом.
На счете будет храниться текущий баланс средств.
Для аккаунта будут доступны два команды : внести деньги (депозит) и снять деньги (вывести).
В командах будет указана сумма, которую необходимо внести или снять.
Мы также определим бизнес-правило, которое проверяет, что команда на снятие средств может быть обработана только в том случае, если запрошенная сумма равна или меньше баланса текущего счета.
При таком подходе можно выделить два события — «Счет зачислен» и «Счет списан» (Средства списаны со счета).
Эти события содержат информацию о сумме, которая была внесена или снята.
Это можно упростить до одного события с положительной или отрицательной суммой, но в этом примере мы разделим их.
На диаграмме ниже показана модель данных.
Обратите внимание, что события имеют «прошедшее время».
Они указывают на то, что происходило в системе в момент написания, и сохраняются только в случае успешной обработки команды.
При таком подходе необходимо соблюдать осторожность, чтобы не перепутать команды с событиями.
Особенно, если они являются зеркальным отражением друг друга.
Последовательность команд может выглядеть следующим образом: 1. депозит {сумма: 100} — депозит 100 2. вывести {сумма: 80 } — вывести 80 3. вывести {сумма: 50 } — вывести 50 Простейшая реализация источника событий требует Журнал событий , который представляет собой просто последовательность событий.
При обработке приведенных выше команд вы получите такой лог.
Третью команду выполнить невозможно, так как запрошенная сумма превышает доступный баланс.
Для получения текущего баланса система должна обрабатывать или «генерировать» события в порядке их возникновения.
Для нашего примера это может выглядеть так: банковский счет { текущий баланс: 0 } (начальное состояние) банковский счет {текущий баланс: 0} (исходное состояние) банковский счет { текущий баланс: 100 } (обработано: счет пополнен, +100) банковский счет {текущий баланс: 100} (обработано: Счет пополнен, +100) банковский счет { текущий баланс: 20 } (обработано: счет дебетован, -80) банковский счет {текущий баланс: 20} (обработано: средства списаны со счета, -80) Текущий баланс рассчитывается путем обработки всех событий до текущего момента.
Поскольку каждое событие имеет неявную метку времени, можно вычислить состояние аккаунта в любой момент времени, обработав все события за необходимый период времени.
Это полный (хотя и тривиальный) пример источника событий.
В реальной системе этот пример, скорее всего, придется расширить.
Может возникнуть необходимость сохранить последовательность команд, чтобы можно было определить, как произошло событие, а также создать отдельный журнал «ошибочных событий», в который будут записываться команды, которые не удалось выполнить, для дальнейшей обработки ошибок и ведения.
полная история успешных и неудачных команд. Со временем, по мере увеличения количества команд, может возникнуть необходимость поддерживать текущий баланс счета, чтобы при получении команды на вывод не требовалось обрабатывать полный список событий для определения возможности выполнения команды (т. , достаточно ли средств на счету).
Это пример производного хранилища, который по сути аналогичен сущностному хранилищу.
Ниже показано, как будет выглядеть хранилище сущностей для нашего примера после обработки всех команд.
Очевидно, что по сравнению с полноценным хранилищем событий (Event Store) это очень примитивный пример.
И это одна из причин, почему многие разработчики используют только хранилище сущностей.
В этом случае текущий баланс счета доступен сразу и нет необходимости обрабатывать все исторические события.
Однако источник событий не исключает хранилища сущностей.
Магазины сущностей часто присутствуют в проектах Event Sourcing. Конец первой части.
Теги: #программирование #java #поиск событий
-
Tesla Model S: Взгляд Поближе
19 Oct, 24 -
Универсальная Теория Афины
19 Oct, 24 -
Полезные Сайты Для Iphone.
19 Oct, 24 -
Контент-Маркетинг В Инфографике
19 Oct, 24
