Bounded context (обмежений контекст) - поняття з DDD: межа, всередині якої терміни й модель мають одне чітке значення. У великій системі одне слово означає різне в різних частинах.
«Товар» у каталозі - опис, фото, характеристики. На складі - залишки, комірка, вага. У бухгалтерії - собівартість і податкова група. Спроба зробити одну модель Product для всіх трьох дає клас на сотні полів, який змінюють усі команди й ніхто не розуміє повністю.
Ідея: кожен контекст має свою модель того, що йому потрібно. Контексти пов'язані через ідентифікатори й явні контракти, а не через спільні таблиці й класи.
Як ділити моноліт на модулі (модульний моноліт):
- Знайти межі за мовою й бізнес-процесами: де змінюється значення термінів, які частини змінюються разом, які команди відповідають за що.
- Модуль = каталог з публічним API:
app/Billing,app/Catalog,app/Shipping. Інші модулі звертаються лише до публічного інтерфейсу (сервіси, події), а не до внутрішніх моделей і таблиць. - Зв'язок між модулями - через події (
OrderPlaced→ Billing створює рахунок) або явні виклики фасаду модуля. - Свої таблиці для модуля. Запити
JOINчерез межу модуля - сигнал, що межа неправильна або потрібна копія даних. - Автоматична перевірка меж: архітектурні тести (Pest
arch(), Deptrac) забороняютьCatalogімпортувати внутрішні класиBilling.
Чому модульний моноліт, а не одразу мікросервіси: межі спершу майже завжди визначають неточно. Перенести код між модулями - рефакторинг; між мікросервісами - міграція даних, нові API й розподілені транзакції. Добре відокремлений модуль легко винести в сервіс пізніше, коли для цього з'явиться справжня причина: незалежне масштабування, окрема команда, інший цикл релізів.