Як не перетворити мікросервіси на пекло
Кейс-стаді від екс-техліда «Нової Пошти». Чому нарізка бекенду по таблицях бази даних веде до краху і як за допомогою Bounded Contexts проєктувати системи, що не ламаються.
Серед зареєстрованих учасників розіграємо 3 місця на курсі «Mastering DDD» (пакет Gold)
Типовий сценарій: моноліт ріжуть на сервіси по таблицях бази. На схемі все виглядає охайно, а в продакшені з'являються розподілені транзакції, блокування й деплої, які доводиться синхронізувати між командами.
Замість одного моноліту ти отримуєш розподілений моноліт. Він повільніший і крихкіший за оригінал.
Без лайвкодингу в IDE – тільки архітектура, системні помилки й реальні рішення. Сергій Сучок покаже на Enterprise/Highload-кейсі, чому Bounded Context не дорівнює сервісу, як будувати Context Map і де насправді проводити межі сервісів.
які зараз розділяють моноліт або тільки планують і хочуть не наступити на граблі, на які до них наступили сотні команд.
але бачать спільну базу, синхронні ланцюжки викликів і релізи, які доводиться координувати між сервісами.
і хочуть упевнено проходити System Design співбесіди та аргументовано захищати поділ системи перед командою й бізнесом.
агрегати, сутності, value objects, але не розуміє, як застосувати DDD на рівні всієї системи та кількох команд.
Як спроба нарізати моноліт по табличках бази створює «розподілене пекло»: розподілені транзакції, блокування, залежні деплої.
Чому Bounded Context – це межа єдиної мови (Ubiquitous Language), а не схеми БД. Від піддоменів (Core / Supporting / Generic) до Context Map: Shared Kernel, Customer–Supplier, Anti-Corruption Layer.
Схема великої системи: як було, чому вперлося в стелю і як розрізали контексти.
Як визначити, чи межа проведена там, де треба.
Побачиш симптоми у власній системі ще до того, як вони стануть інцидентами.
Зрозумієш, чому схема бази – погана підказка для поділу на сервіси.
Shared Kernel, Customer–Supplier і ACL на прикладі великої системи.
Щоб оцінити, чи межі сервісів у твоїй системі проведені там, де треба.
Після реєстрації ти отримаєш посилання на трансляцію в день події.
Сергій Сучок проведе ефір і розбере на схемах, як Стратегічний DDD рятує мікросервіси від розподіленого моноліту.
Архітектурний розбір без лайвкодингу, відповіді на питання та розіграш 3 місць на курсі «Mastering DDD».
Пакет Gold практичного Advanced-курсу Сергія Сучка «Mastering Domain-Driven Design: DDD, CQRS та Event Sourcing на практиці». Старт курсу – 30 листопада. Розіграш проведемо на вебінарі серед зареєстрованих учасників.
Детальніше про курс →Серед зареєстрованих учасників розіграємо 3 місця на курсі «Mastering DDD» (пакет Gold).
Вкажи контактні дані, щоб отримати посилання на трансляцію вебінару Сергія Сучка про Стратегічний DDD.
