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-застосунків невиправдано.
