Управляемая событиями архитектура и структура событий

Question

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

При подъеме событие, которое модель является наиболее подходящим:

1. Имя события «CustomerUpdate» и включают в себя всю информацию (обновляется или нет) о клиенте
2. Имя события «CustomerUpdate» и включают только ту информацию, которая действительно обновлена.
3. Назовите событие «CustomerUpdate» и укажите минимальную информацию (идентификатор) и/или URI, чтобы потребитель мог получить информацию об этом Клиенте.

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

Thx для ваших ответов и времени.

Answer 1

Имя события "CustomerUpdate"

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

Ваше имя события «CustomerUpdate» звучит неоднозначно в этом отношении, поскольку оно может описывать что-то в прошлом или что-то в будущем.

CustomerUpdated было бы лучше, но даже тогда, Обновленный еще один неоднозначный термин, и неспецифические в бизнес-контексте. Почему в этом случае клиент был обновлен? Это потому, что они изменили свои платежные реквизиты? Переехал домой? Были ли они обновлены с серебра на золото? События могут быть сделаны по мере необходимости.

Это может показаться на первый взгляд, overthinking, но именование события становится особенно актуальным, как вы удалите данные и контекст от полезной нагрузки событий, двигаясь больше к тощим события («вариантом 3» из вашего вопроса, которые я обсуждаю ниже).

Это не означает, что всегда необходимо определять события на этом уровне детализации, только то, что это путь, который открыт для вас на раннем этапе проекта, который позже может выплатить дивиденды (или может привести вас к болоту с тысячами типов событий).

Возвращаясь к вашему фактическому вопрос, давайте рассмотрим каждый из ваших вариантов, в свою очередь:

Название события «CustomerUpdate» и включают в себя всю информацию (обновленную или нет) о клиенте

Назовем этот «узор» Fat сообщение.

Жирные сообщения представляют состояние описанного объекта в данный момент времени со всем контекстом события, присутствующим в полезной нагрузке.Они интересны, потому что само сообщение представляет собой контракт между сервисом и потребителем. Они могут использоваться для передачи изменений состояния между бизнес-доменами, где может быть предпочтительным, чтобы весь контекст события присутствовал при обработке сообщений потребителем.

Преимущества:

• самосогласованного - можно употреблять совершенно без знания других систем.
• Простота потребления (upsert).

Недостатки:

• Хрупкое - договор между службой и потребителем связан с самим сообщением.
• Легко перезаписывать текущие данные старыми данными, если сообщения поступают в неправильном порядке.
• Большой.

Имя события «CustomerUpdate» и включают в себя только информацию о том, что есть на самом деле были обновлены

Давайте назовем эту модель сообщение Delta.

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

Преимущества:

• Меньше чем жир сообщения

Недостатки:

• Хрупкие - подобные сообщения Fat, контракт встраивается в сообщении.
• Легко перезаписать текущие данные старыми данными.
• комплекс для создания и потребления

Название события «CustomerUpdate» и включают минимальную информацию (идентификатор) и/или URI, чтобы позволить потребителю извлекает информацию об этом Клиента.

Назовем это Skinny.

Тощие сообщения отличаются от других шаблонов сообщений, которые вы определили, поскольку контракт на обслуживание/потребитель больше не является явным в сообщении, но подразумевается, что в какой-то момент времени потребитель будет извлекать контекст события. Это отделяет контракт и обмен сообщениями, что хорошо.

Это может быть или не быть хорошо обеспечено межсетевым обменом доменами в зависимости от того, как настроено ваше предприятие. Поскольку полезная нагрузка события настолько мала (как правило, это только идентификатор), нет никакого контекста, кроме имени события, на котором потребитель может основывать решения по обработке; поэтому становится более важным удостовериться, что событие названо соответствующим образом, особенно если есть несколько способов, которыми потребитель мог ответить на сообщение CustomerUpdated.

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

Преимущества:

• разъединяет контракт на обслуживание с сообщением.
• Информация о мероприятии, содержащемся в названии мероприятия.
• Естественно, идемпотент (с отметкой времени).
• Вообще крошечный.
• Простое создание и потребление.

Недостатки:

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

При подъеме события, какой образец наиболее подходит?

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