[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"question-arkhitektura-prilozheniy-chto-takoe-event-driven-architecture-eda":3},{"id":4,"slug":5,"topicId":6,"topicSlug":7,"topicName":8,"topicEmoji":9,"question":10,"answer":11,"codeLang":12,"codeSrc":12,"important":12,"commonMistakes":12,"modernUsage":12,"difficulty":13,"tags":14,"related":19,"progress":20,"seo":21},128,"chto-takoe-event-driven-architecture-eda",3,"arkhitektura-prilozheniy","Архитектура приложений","🏗️","Что такое Event-Driven Architecture (EDA)","Event-Driven Architecture (EDA) — архитектурный стиль, в котором компоненты системы взаимодействуют посредством событий. Событие — факт, который произошёл в системе (например, «Платёж совершён», «Клиент зарегистрирован»). По аналогии с реальной жизнью: когда в банке совершается операция, кассир не обзванивает все отделы лично, а выписывает документ, который далее маршрутизируется по нужным адресатам.\n\n### Схема взаимодействия\n\n```\n┌─────────────┐   PaymentCreated   ┌──────────────┐\n│  Сервис     │───────────────────▶│  Брокер      │\n│  Платежей   │                    │  сообщений   │\n└─────────────┘                    │  (Kafka)     │\n                                   └──────┬───────┘\n                                          │\n                         ┌────────────────┼────────────────┐\n                         ▼                ▼                ▼\n                  ┌────────────┐  ┌────────────┐  ┌────────────┐\n                  │  Сервис    │  │  Сервис    │  │  Сервис    │\n                  │ Уведомлений│  │  Аналитики │  │  Комплаенс │\n                  └────────────┘  └────────────┘  └────────────┘\n```\n\n### Основные топологии EDA\n\n**1. Broker Topology (через брокер)** — все события публикуются в брокер (Kafka, RabbitMQ), подписчики сами забирают нужные. Нет центрального оркестратора.\n\n**2. Mediator Topology (через посредник)** — центральный компонент (медиатор) координирует обработку события, рассылая команды обработчикам.\n\n### Типы событий\n\n- **Event Notification** — уведомление о факте. Содержит минимум данных. Подписчик сам запрашивает детали при необходимости.\n- **Event-Carried State Transfer** — событие несёт в себе все необходимые данные, чтобы подписчик мог обработать его без дополнительных запросов.\n- **Domain Event** — событие, имеющее смысл в домене бизнеса (`PaymentExecuted`, `AccountBlocked`).\n\n### Пример на Spring с Kafka\n\n\u003Cdetails>\u003Csummary>Пример кода\u003C\u002Fsummary>\n\n```java\n\u002F\u002F Публикация события\n@Service\npublic class PaymentService {\n\n    private final KafkaTemplate\u003CString, PaymentEvent> kafkaTemplate;\n\n    @Transactional\n    public void executePayment(PaymentCommand cmd) {\n        Payment payment = createAndSavePayment(cmd);\n\n        kafkaTemplate.send(\"payment-events\",\n            new PaymentExecutedEvent(payment.getId(), payment.getAmount(),\n                LocalDateTime.now()));\n    }\n}\n\n\u002F\u002F Подписчик\n@Component\npublic class NotificationEventHandler {\n\n    @KafkaListener(topics = \"payment-events\", groupId = \"notification-service\")\n    public void onPaymentExecuted(PaymentExecutedEvent event) {\n        notificationService.sendPaymentConfirmation(event);\n    }\n}\n```\n\n\u003C\u002Fdetails>\n\n### Плюсы\n\n- Слабая связанность (low coupling) — продюсер не знает о подписчиках.\n- Масштабируемость — можно добавлять подписчиков без изменения продюсера.\n- Отказоустойчивость — сбой одного подписчика не влияет на остальных.\n- Асинхронность — высокая пропускная способность.\n\n### Минусы\n\n- Сложность отладки и трассировки.\n- Eventual consistency вместо немедленной согласованности.\n- Необходимость обрабатывать дублирование событий (идемпотентность).\n- Сложность гарантии порядка обработки.\n\n> **На собеседовании:** Интервьюер хочет услышать о различии между типами событий (Notification vs Event-Carried State Transfer) и понимание eventual consistency. Частая ошибка — не упоминать проблему идемпотентности обработки событий.","","middle",[15,16,17,18],"kafka","event-driven","architecture","messaging",[],null,{"title":22,"description":23,"ogTitle":22,"ogDescription":24,"keywords":25,"schemaAnswer":33,"featuredSnippetReady":34},"Event-Driven Architecture (EDA) — Gymterview","Event-Driven Architecture — стиль, где компоненты взаимодействуют через события. Топологии: Broker и Mediator. Типы событий. Примеры с Kafka и Spring.","Event-Driven Architecture — стиль, где компоненты взаимодействуют посредством событий через брокер сообщений.",[26,27,28,29,30,31,32],"Event-Driven Architecture","EDA","событийная архитектура","Kafka","брокер событий","Domain Event","асинхронное взаимодействие","Event-Driven Architecture (EDA) — архитектурный стиль, в котором компоненты системы взаимодействуют посредством событий (фактов, произошедших в системе). Основные топологии: Broker (события публикуются в брокер, подписчики забирают нужные) и Mediator (центральный посредник координирует обработку). Типы событий: Event Notification, Event-Carried State Transfer и Domain Event. Плюсы: слабая связанность, масштабируемость, отказоустойчивость. Минусы: сложность отладки, eventual consistency, необходимость обеспечения идемпотентности.",true]