Event Sourcing - події як джерело істини

Event Sourcing зберігає не поточний стан, а повну послідовність подій, що його змінювали; стан відновлюється їх програванням.

Яку проблему вирішує

Звичайне сховище тримає лише останній стан і втрачає історію: як саме об'єкт дійшов до нього, які зміни відбулися й коли. Для аудиту, аналітики чи відтворення минулих станів цього недостатньо.

Як вирішує

Кожна зміна записується як незмінна подія в журнал (event store). Поточний стан - це результат послідовного застосування всіх подій. Можна відтворити стан на будь-який момент і отримати повний аудит "безкоштовно".

У прикладі лише ілюстрація ідеї. Повна реалізація потребує event store, replay подій та версіонування.

class OrderCreated
{
  public function __construct(
    public int $orderId, 
    public int $userId
  ) {}
}

class OrderAggregate
{
  private int $orderId;

  public function apply(OrderCreated $event): void
  {
    $this->orderId = $event->orderId;
  }
}

event(new OrderCreated(1, 10));

Де застосовувати

• Домени з вимогами до аудиту й відтворюваності: фінанси, складський облік, бухгалтерія.
• Часто йде в парі з CQRS: події - джерело істини для write-боку, read-моделі будуються з них.

Плюси та мінуси

• + Повний аудит і можливість відтворити стан на будь-який момент.
• + Події - природне джерело для аналітики та інтеграцій.
• − Складніша інфраструктура: event store, replay, версіонування подій.
• − Помітно складніше моделювання; для більшості CRUD-застосунків невиправдано.