Что не так с Bounded Context Canvas? И почему его никто не использует? Bounded Context Canvas Ника Тьюна - это визуальный темплейт, который помогает команде спроектировать и задокументировать один bounded context в терминах бизнеса, общего языка, интерфейсов и зависимостей. Есть оформленная методика заполнения и рекомендации и список решаемых задач и выгод, но… много вы их видели в дикой природе? Попробуйте найти реальные кейсы его использования и вы их не найдете :) Практические все примеры – от самого Ника, консультантов по DDD и с выступлений на конференциях. Так почему Канвас не прижился? ▪️Начнем с того, что канвас - это артефакт, а не процесс. Ценность воркшопов во взаимодействии, выявлении противоречий, построении общего языка. Команда уже получила инсайты в голову во время воркшопа. И канвас, получается, – финальный бюрократический артефакт, который никто не читает. Почему? См. следующий пункт ▪️У Bounded Context Canvas нет связи с повседневной работой. Элементы не переводятся в конкретные рабочие элементы в повседневной работе. ▪️И контрольный выстрел – у канваса около десяти секций и почти все заполняются гипотезами. Если команда не испытывает конкретную боль (например, непонятно, кто отвечает за сервис), то заполнение абстрактных полей вроде «Domain Roles» или «Model Traits» кажется бессмысленным академическим упражнением Сам Ник Тьюн говорит, что канвас - это чеклист для обнаружения проблем, а не документ для хранения. Заполняя формальную структуру можно увидеть проблемы и расхождения. Но если команда не знает, что искать, она просто заполняет поля и не видит редфлагс. Если обобщить, то Bounded Context Canvas решает несуществующую для большинства команд проблему (документация bounded context), тогда как реальные проблемы лежат в области коммуникации, интеграции и повседневных архитектурных решений. Хорошие, живые альтернативы: ▪️EventStorming с немедленным переходом в архитектуру и код ▪️Context Map как «живой» документ (потому что именно связи вызывают большинство проблем)