Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Що означає «event sourcing»?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Event Sourcing** - архітектурний підхід, за якого система не зберігає поточний стан об'єкта напряму, а зберігає всі події, які до нього призвели; поточний стан отримують, відтворивши події по порядку. **Ключове:** це дає повну історію змін, легкий відкат і природну інтеграцію з подієвою архітектурою (EDA), хоч і ускладнює зберігання і читання даних.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**Event Sourcing** - це архітектурний підхід, за якого система **не зберігає поточний стан об'єкта напряму**, а зберігає **всі події, які до нього призвели**. ### Суть Кожна зміна даних записується як подія: > «Створено замовлення», «Додано товар», «Оплату отримано». Щоб отримати поточний стан, система просто відтворює всі події по порядку. Таким чином, база даних стає журналом історії, а не знімком поточного стану. ### Приклад Звичайний підхід зберігає: ```javascript Order: {id: 1, status: "paid"} ``` Event Sourcing зберігає: ```javascript 1. OrderCreated 2. ItemAdded 3. PaymentReceived ``` З цих подій можна в будь-який момент перерахувати поточний стан замовлення. ### Навіщо це потрібно - **Повна історія змін** - зручно для аудиту й аналітики. - **Легкий відкат і відтворення** стану. - **Природна інтеграція з подієвою архітектурою (EDA)**. - **Гнучкість** - можна перерахувати дані, якщо змінилися бізнес-правила. ### Мінуси - Ускладнює зберігання і читання даних (потрібні «проєкції» для швидких запитів). - Складніше реалізувати транзакційну цілісність. **Підсумок:** > **Event Sourcing** - це спосіб зберігати не результат, а **історію подій**, > що дозволяє точно відновити минуле і гнучко керувати станом системи.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.