advanced
Bounded contexts
Используйте bounded contexts как candidate service boundaries, когда language, model, rules и ownership достаточно различаются для autonomy.
В DDD bounded context владеет согласованным ubiquitous language, моделью и правилами. Кандидаты в границы microservices появляются, где language, инварианты и ownership настолько различаются, что совместная эволюция дороже интеграции.
Не каждый bounded context становится сервисом — начните с модулей modular monolith и извлекайте при необходимости autonomy или scale.
На интервью: покажите термины с разным смыслом в billing и catalog; объясните anti-corruption layers между contexts.
Типовые ошибки: сервис на сущность (OrderService, CustomerService); общая «enterprise» модель; границы только по org chart.
Компромисс — гибкость против сложности: знайте, когда достаточно более простого пути.
Чеклист:
- Перечислите термины и правила, различающиеся между contexts.
- Назначьте одну owning team на context.
- Используйте ACL или translated DTO на точках интеграции.
- Извлекайте сервисы, когда release или scale pressure это оправдывает.