Что такое Event-Driven Architecture?

#Команда против события

#Поток событий

Сравните с синхронным подходом: Orders вызывает по HTTP четыре сервиса, ждёт их ответов, знает их адреса и падает, если любой недоступен. В EDA оформление заказа завершается, как только событие надёжно опубликовано.

#Стили событий

#Event Notification

{ "type": "OrderPlaced", "orderId": "ord_1042", "occurredAt": "2025-09-30T10:15:00Z" }

Минимальное событие. Потребитель, которому нужны детали, запрашивает их у Orders API. Плюс — маленький контракт; минус — обратная связанность (запрос к источнику) и нагрузка на него.

#Event-Carried State Transfer

{
  "type": "OrderPlaced",
  "orderId": "ord_1042",
  "customer": { "id": "c_7", "email": "ann@example.uz", "tier": "gold" },
  "items": [ { "sku": "PHONE-1", "qty": 1, "price": 7990000 } ],
  "total": 7990000,
  "occurredAt": "2025-09-30T10:15:00Z"
}

Событие несёт всё нужное — потребители не обращаются к источнику и могут хранить локальную копию данных (например, Shipping хранит адреса клиентов). Плюс — автономность; минусы — больше данных в сообщениях, дублирование, контракт шире.

#Event Sourcing и CQRS

События — не только интеграция, но и способ хранения (см. вопросы про Event Sourcing и CQRS).

#Топологии обработки

• Broker topology / хореография — нет центрального координатора, каждый реагирует на события. Гибко, но поток процесса неявный.
• Mediator topology / оркестрация — центральный процесс (сага, workflow) управляет шагами командами и слушает события.

#Надёжность

Проблемы, с которыми придётся жить:

• At-least-once доставка → дубли → идемпотентные обработчики.
• Порядок не гарантирован глобально → партиционирование по ключу агрегата, версии в событиях, проверка «событие старее текущего состояния».
• Eventual consistency → UI и процессы должны учитывать задержку.
• Ядовитые сообщения → ретраи с ограничением и Dead Letter Queue.

#Контракты событий

namespace Shop.Orders.Contracts.V1;

/// <summary>Опубликовано после успешного оформления заказа.</summary>
public sealed record OrderPlaced(
    Guid EventId,               // идентификатор для идемпотентности
    Guid OrderId,
    Guid CustomerId,
    decimal Total,
    string Currency,
    DateTimeOffset OccurredAt,
    int SchemaVersion = 1);

Правила эволюции:

• Добавлять поля — безопасно (потребители игнорируют неизвестное); удалять и переименовывать — нет.
• Несовместимые изменения — новый тип/версия (OrderPlacedV2), публиковать обе версии на период миграции.
• Реестр схем (Schema Registry для Avro/Protobuf в Kafka) или контрактные тесты (Pact).
• CloudEvents — стандартный конверт метаданных (id, source, type, time, datacontenttype).

#Когда EDA уместна

#Вопросы на засыпку

#Итог

Event-Driven Architecture связывает компоненты через факты о произошедшем: производитель не знает потребителей, новые реакции добавляются без изменения источника, пики сглаживаются брокером. Плата — eventual consistency, дубли, порядок и сложность наблюдения; поэтому EDA требует outbox, идемпотентных потребителей, DLQ, версионирования контрактов и хорошей трассировки.