В большой компании слово «клиент» может означать совершенно разные вещи. Для продаж это компания и контактные лица. Для биллинга — плательщик. Для поддержки — пользователь конкретного продукта.
Попытка создать одну универсальную модель клиента для всех часто заканчивается огромным объектом, который меняют десятки команд и боятся трогать.
Bounded Context предлагает признать реальность: разные части бизнеса могут использовать собственные модели и правила.
Какую проблему мы решаем
Bounded Context — это явная смысловая граница, внутри которой термины и бизнес-правила имеют однозначное значение.
Например, продажи, доставка и финансы могут по-разному смотреть на заказ. Вместо одной модели на все случаи каждая область управляет своей частью, а между ними существуют понятные контракты.
Граница здесь важнее технологии. Один контекст может быть модулем монолита или отдельным сервисом.
Что получает бизнес
Главный эффект — изменения локализуются ближе к той части бизнеса, где они возникли.
Если финансовые правила поменялись, компании не обязательно одновременно переделывать продажи, логистику и поддержку. Это уменьшает количество согласований и снижает риск того, что локальное изменение неожиданно затронет весь продукт.
Второй эффект — яснее ответственность. У конкретной бизнес-области появляется понятный владелец модели, правил и приоритетов. Команды меньше спорят о том, какая «единая истина» правильная для всех.
Для растущей компании это напрямую связано со скоростью: чем меньше независимые направления вынуждены синхронизировать каждое изменение, тем быстрее они могут развиваться.
Что получает команда
Команда получает ограниченную область, которую можно понимать целиком. Термины внутри неё стабильнее, а зависимости от соседних частей системы проходят через явные интерфейсы.
Это уменьшает случайные связи и помогает не превращать общую модель данных в место, где встречаются все требования компании.
Но хорошие границы нельзя получить механическим делением таблиц или организационной схемы. Нужно понимать реальные бизнес-процессы и язык предметной области.
Что получает клиент
Клиент редко видит bounded contexts напрямую. Он видит, насколько быстро компания может менять отдельные части продукта и насколько меньше одно изменение ломает другое.
Хорошие границы позволяют продуктам развиваться независимо, сохраняя согласованное поведение на стыках.
Чем мы за это платим
Цена — необходимость синхронизировать данные между контекстами и мириться с тем, что единой модели на всё больше нет.
Иногда одна и та же сущность будет представлена в нескольких местах. Потребуются API, события или другие контракты. Появятся вопросы о том, кто является источником конкретного факта.
Кроме того, неверно выбранная граница может быть хуже её отсутствия: команды начнут постоянно ходить через неё ради каждого изменения.
Когда Bounded Context не нужен
Для небольшого продукта с одной командой и простой предметной областью сложная доменная декомпозиция может быть преждевременной.
Если все участники одинаково понимают термины и меняют систему вместе, достаточно простых модульных границ.
Что стоит спросить перед решением
- Какие части бизнеса используют одинаковые слова в разном смысле?
- Какие изменения чаще всего требуют координации слишком большого числа команд?
- Где находится реальная ответственность за бизнес-правила?
- Какие данные должны принадлежать одной области, а какие достаточно передавать соседям?
- Совпадают ли наши технические границы с тем, как реально устроен бизнес?
В итоге
Bounded Context — это не способ красиво разложить код по папкам.
Его бизнес-смысл в том, чтобы разные части компании могли развивать собственные правила, не превращая каждое изменение в общекорпоративную операцию.