Зачем нужен принцип EDA, если есть принцип Dependency Inversion Principle?

Зачем нужен принцип EDA, если есть принцип Dependency Inversion Principle?

EDA (Event-Driven Architecture) и DIP (Dependency Inversion Principle) решают разные проблемы. Хотя оба помогают снизить связанность кода, они работают на разных уровнях абстракции.

1. Быстрое определение

DIP (Dependency Inversion Principle):

• Паттерн проектирования
• Работает на уровне классов и модулей
• Инверсия зависимостей через интерфейсы
• Локальное решение для конкретных компонентов

EDA (Event-Driven Architecture):

• Архитектурный паттерн
• Работает на уровне всей системы
• Компоненты общаются через события
• Глобальное решение для слабой связанности

2. Проблема в DIP: жёсткая линейная связь

# ПРОБЛЕМА: Прямые зависимости (нарушение DIP)
class PaymentProcessor:
    def process(self, amount):
        # Когда процесс платежа завершён, что дальше?
        pass

class OrderService:
    def __init__(self):
        self.payment = PaymentProcessor()
    
    def create_order(self, order):
        # Что если нужно уведомить пользователя?
        # Отправить email?
        # Обновить статистику?
        self.payment.process(order.amount)
        # Прямая связь!

# Если добавить новую функцию (например, email), нужно менять OrderService

Решение DIP:

# DIP: Инверсия через интерфейс
from abc import ABC, abstractmethod

class PaymentHandler(ABC):
    @abstractmethod
    def handle_payment(self, amount):
        pass

class PaymentProcessor(PaymentHandler):
    def handle_payment(self, amount):
        print(f"Processing ${amount}")

class OrderService:
    def __init__(self, payment_handler: PaymentHandler):
        self.payment = payment_handler
    
    def create_order(self, order):
        self.payment.handle_payment(order.amount)

Проблема: EDA решает другую проблему!

# DIP не поможет когда нужно несколько действий:
class OrderService:
    def __init__(self, payment: PaymentHandler, email: EmailHandler, 
                 analytics: AnalyticsHandler):
        self.payment = payment
        self.email = email
        self.analytics = analytics
    
    def create_order(self, order):
        self.payment.handle_payment(order.amount)
        self.email.send_confirmation(order)
        self.analytics.track_order(order)

# Результат: OrderService имеет множественные зависимости
# Сложно добавлять новые обработчики (нужно менять конструктор)
# Код становится жёстче, а не гибче!

3. Решение EDA: развязывание через события

# EDA: Компоненты общаются через события
from typing import Callable, List
from dataclasses import dataclass

@dataclass
class OrderCreatedEvent:
    order_id: str
    amount: float
    customer_email: str

# Event Bus — центральная шина для событий
class EventBus:
    def __init__(self):
        self.subscribers: dict[str, List[Callable]] = {}
    
    def subscribe(self, event_type: str, handler: Callable):
        if event_type not in self.subscribers:
            self.subscribers[event_type] = []
        self.subscribers[event_type].append(handler)
    
    def publish(self, event):
        event_type = type(event).__name__
        if event_type in self.subscribers:
            for handler in self.subscribers[event_type]:
                handler(event)

# OrderService больше ничего не знает
class OrderService:
    def __init__(self, event_bus: EventBus):
        self.event_bus = event_bus
    
    def create_order(self, order):
        # Просто создаём заказ
        saved_order = self.save_to_db(order)
        
        # Публикуем событие
        event = OrderCreatedEvent(
            order_id=saved_order.id,
            amount=order.amount,
            customer_email=order.customer_email
        )
        self.event_bus.publish(event)

# Обработчик платежей
class PaymentHandler:
    def __init__(self, event_bus: EventBus):
        event_bus.subscribe('OrderCreatedEvent', self.handle_order_created)
    
    def handle_order_created(self, event: OrderCreatedEvent):
        print(f"Processing payment for {event.order_id}")
        # Обработка платежа

# Обработчик email
class EmailHandler:
    def __init__(self, event_bus: EventBus):
        event_bus.subscribe('OrderCreatedEvent', self.send_confirmation)
    
    def send_confirmation(self, event: OrderCreatedEvent):
        print(f"Sending confirmation to {event.customer_email}")

# Аналитика
class AnalyticsHandler:
    def __init__(self, event_bus: EventBus):
        event_bus.subscribe('OrderCreatedEvent', self.track_order)
    
    def track_order(self, event: OrderCreatedEvent):
        print(f"Tracking order {event.order_id}")

# Сборка системы
event_bus = EventBus()
order_service = OrderService(event_bus)
payment = PaymentHandler(event_bus)
email = EmailHandler(event_bus)
analytics = AnalyticsHandler(event_bus)

# Создать заказ — и все обработчики получат уведомление!
order = Order(amount=100, customer_email="user@example.com")
order_service.create_order(order)

4. Ключевые различия

5. Когда использовать

DIP используй для:

• Простых классов с 1-2 зависимостями
• Когда порядок выполнения важен
• Когда компоненты работают тесно вместе

class UserRepository:
    pass

class UserService:
    def __init__(self, repo: UserRepository):
        self.repo = repo  # Просто инверсия зависимости

EDA используй для:

• Множества обработчиков одного события
• Когда новые обработчики появляются часто
• Асинхронных операций
• Микросервисной архитектуры

# EDA лучше подходит для этого
class OrderService:
    def __init__(self, event_bus):
        self.event_bus = event_bus
    
    # Не нужно знать ни о каких обработчиках!
    def create_order(self, order):
        self.event_bus.publish(OrderCreatedEvent(order))

6. Комбинирование DIP и EDA

# Best practice: используй оба подхода вместе
from abc import ABC, abstractmethod

# DIP: интерфейсы для обработчиков
class OrderEventHandler(ABC):
    @abstractmethod
    def handle(self, event: OrderCreatedEvent):
        pass

# EDA: события через шину
class EventBus:
    def __init__(self):
        self.handlers: dict = {}
    
    def subscribe(self, event_type, handler: OrderEventHandler):
        if event_type not in self.handlers:
            self.handlers[event_type] = []
        self.handlers[event_type].append(handler)
    
    def publish(self, event):
        handlers = self.handlers.get(type(event).__name__, [])
        for handler in handlers:
            handler.handle(event)  # DIP: используем интерфейс!

# Конкретные обработчики
class PaymentOrderHandler(OrderEventHandler):
    def handle(self, event: OrderCreatedEvent):
        print(f"Payment for {event.order_id}")

class EmailOrderHandler(OrderEventHandler):
    def handle(self, event: OrderCreatedEvent):
        print(f"Email to {event.customer_email}")

7. Вывод

DIP и EDA решают разные проблемы:

• DIP — как структурировать зависимости класса
• EDA — как связывать компоненты в большой системе

EDA нужен потому что:

1. DIP сложно применить когда обработчиков много
2. DIP требует менять конструктор при добавлении нового обработчика
3. EDA позволяет динамически добавлять/удалять обработчики
4. EDA лучше для асинхронных операций

Используй вместе:

• DIP внутри обработчиков
• EDA для связи между компонентами