Проектируем bounded context с помощью Bounded Context Canvas: рецепт воркшопа

Среди тем предстоящей конференции TechLead Conf 2020 будет детальное обсуждение Domain-Driven Design и EventStorming. Помимо подготовки 2-слотового доклада Константина Густова о DDD, доклада Сергея Баранова об EventStorming и митапа, во время которого мы будем создавать DDD-радар, мы решили перевести статью об одном из самых популярных способов проектирования bounded context.

Как разбить большую систему на мелкие более управляемые компоненты? Мне часто задают этот вопрос, поэтому я собрал свои знания в эту статью.

В DDD большая система декомпозируется на ограниченные контексты (прим. переводчика: здесь и далее они будут упоминаться как bounded contexts), которые становятся естественными границами — как микросервисы в коде и как команды в организации.

Нет способа легко и быстро определить хорошие границы bounded context. Для этого необходимо обширное и глубокое знание бизнеса и предметной области. Этот формат воркшопа разработан с учетом обеих этих потребностей и использует два инструмента для поиска наиболее эффективного дизайна системы: EventStorming и Bounded Context Canvas.



«Я разработал этот канвас в процессе проведения воркшопов по DDD на публичных мероприятиях и корпоративных сессиях. Не стесняйтесь менять его структуру, если найдете форматы, которые лучше подходят именно для вас».

Рецепт

Основной рецепт состоит из следующих действий:

1. EventStorming (минимум 1 час).
2. Моделирование кандидатов на bounded context (минимум 30 минут).
3. Моделирование потока доменных сообщений (минимум 30 минут).
4. Bounded Context Canvas (минимум 90 минут).
5. Создание контекстных карт (минимум 45 минут).

В качестве отправной точки, я рекомендую выделить на этот воркшоп целый день. Это поможет понять, сколько времени вам действительно нужно, чтобы провести воркшоп правильно. Если собирать всех вместе дорого (трудоемко), попробуйте сразу выделить два дня, чтобы все успеть.

В идеале, участниками должны быть эксперты предметной области и технические эксперты. Если это трудно организовать, то постарайтесь, чтобы эксперты предметной области были на воркшопе хотя бы первый час.

Основные принципы моделирования

Для проведения сессии с экспертами потребуется просторное помещение. Если вы выберете маленькую аудиторию, то скорее всего будете разочарованы результатами. Каждой группе из 4 человек понадобится как минимум 4 метра на стене.

Я опишу свою методику в свободной форме, без жесткого регламента. Однако имейте в виду:

«Мы постоянно переключаемся между пространством проблемы и пространством решения. Мы ищем информацию, создаем модель, ищем дополнительную информацию, уточняем модель и т.д.»

И еще один важный момент: цель сессии — выработать варианты и развить способность предлагать лучшие варианты в будущем.

1. EventStorming

Для проектирования системы, вам нужны две вещи: достаточно хорошее общее представление обо всей системе и достаточно глубокое понимание деталей в каждой области. Для этого начнем с EventStorming.

EventStorming — это метод совместного проектирования, позволяющий моделировать большую проблемную область от начала до конца, а также позволяющий детализировать большое число деталей там, где это необходимо.



Если вы делаете это впервые, я рекомендую выделить 1-2 часа на EventStorming. После завершения EventStorming я рекомендую разделиться на группы по 4 человека.

На TechLead Conf 2020 Сергей Баранов расскажет о практическом опыте применения EventStorming.

2. Поиск кандидатов на bounded context

После того, как ваш домен смоделирован широко и глубоко на EventStorming, можно начать группировать и объединять фрагменты в bounded context.



Существует множество методов для определения bounded context. Я рекомендую начать со следующих:

• Начните с ценности — определите основные части домена, которые имеют наибольшую ценность для бизнеса.
• Начните с простого — создайте наивную модель, разбив временную шкалу на последовательные шаги.
• Ищите ключевые события — бизнес-события, которые влияют на различные части бизнес-процесса.

В первый раз потратьте не более 30 минут на это задание. Предложите группе создать исходную модель bounded context в качестве отправной точки. Она не должна быть идеальной и вряд ли будет окончательным решением.

Выходные данные должны быть оформлены списком имен bounded context на флипчарте или бумаге. Нельзя физически изменять EventStorming, если у вас несколько групп.

Следующие шаги

Возможно, вы сразу увидите несколько способов моделирования системы. Выберите пока одну из них для работы и запишите другие возможные модели (они будут полезны позже). Вы также можете понять, что вам не хватает информации о домене. Если так, проведите еще один раунд EventStorming.

3. Моделирование потока сообщений домена

Один из способов проверки правильности вашего дизайна и поиска точек улучшения — это визуализировать взаимодействие bounded contexts в полных бизнес-сценариях системы.

Если поток домена получился сложным, с большим количеством зависимостей и двунаправленными связями, значит, ваш дизайн хрупок и нуждается в дальнейшем анализе.

Существует множество методов визуализации, которые можно использовать для моделирования потоков и вариантов использования, включая диаграммы последовательности UML и диаграммы вариантов использования UML. Я советую использовать вариант доменного повествования.

При моделировании потока сообщений предметной области bounded contexts — это действующие лица в истории. Таким образом, типичная история начинается с того, что пользователь пытается достичь некоторой цели, а взаимодействие между bounded contexts направлено на то, чтобы предоставить пользователю решение.


Выдуманный пример потока сообщений домена

Моделирование стратегических потоков домена позволяет получить обратную связь по предложенным bounded contexts. Оно показывает, как контексты сотрудничают друг с другом и зависят друг от друга для выполнения полного бизнес-процесса. Это может помочь найти альтернативный дизайн.

Вопрос, который вы должны себе задавать: соответствует ли описание каждого bounded context той роли, которую он играет в доменном потоке. Если нет, то вероятно, что название или границы контекста требуют редизайна.

Следующие шаги

Поскольку ваши доменные потоки определяют отношения между bounded contexts, вы можете сразу же обнаружить очевидные недостатки дизайна. Вы можете вернуться к предыдущему действию и обновить кандидатов на bounded context или выполнить вторую итерацию EventStorming. Вы также можете записать свои мысли о дизайне и собрать больше информации о последующих действиях, прежде чем приступить к редизайну.

4. Bounded Contexts Canvas

Следующим этапом проектирования является разработка кандидатов на bounded context, с помощью детализации ключевых критериев дизайна. Ваша команда должна выбрать bounded context, который вы считаете наиболее важным. Ограничьте обсуждение максимум 3 минутами. Не критично быть на 100% точным.

Теперь нарисуйте Bounded Context Canvas и выполните следующие шаги, чтобы заполнить детали. Я рекомендую использовать 1 лист флипчарта или бумагу аналогичного размера.
Выполнив перечисленные шаги, повторяйте процесс, пока не определите все свои bounded contexts. Постарайтесь поделить свое время поровну между выявленными кандидатами на bounded context.

4.1 Определение общего контекста

Начните с определения названия вашего bounded context и его описания. Описание должно показывать цель контекста в домене и его роль в бизнесе, а не детали реализации.

Далее нужно сделать стратегическую классификацию. Является ли bounded context основной частью системы, вспомогательным элементом, общим или чем-то еще? Прочитайте пост Владика, если вам нужна помощь в выборе.


В качестве примера, заполненный Bounded Context Canvas после прохождения 1-го шага.

Следующие шаги

Если вы не можете придумать четкое название, или написать связное, точное описание, или ваши термины Ubiquitous Language (UL) неоднозначны — рассматривайте это как обратную связь для дизайна. Подумайте о перепроектировании границ или сделайте заметку и вернитесь позже (обычно лучше вернуться позже).

4.2 Уточнение бизнес-правил и формирование общего языка

Теперь вернитесь к EventStorming и посмотрите на заметки для этого bounded context. Найдите наиболее важные бизнес-правила и политики, затем попробуйте выбрать 3 самые важные и добавить их на канвас.

Константин Густов на TechLead Conf 2020 расскажет о многолетнем опыте работы с Ubiquitous Language и другими составляющими DDD в Райффайзене.

Это также подходящий момент для поиска ключевых бизнес-слов или фраз, чтобы добавить их на канвас в раздел «Ubiquitous Language». Вы продолжите добавлять слова и фразы на протяжении всего воркшопа, сейчас это только начальная точка.

4.3 Анализ возможностей

Следующий шаг — проработка возможностей, предоставляемых bounded context. Это не только проясняет то, что он делает, но и дает много обратной связи для дизайна. Вы можете задавать такие вопросы, как:

• Не перегружен ли этот контекст обязанностями?
• Выглядят ли возможности связанными?
• Соответствуют ли возможности названию и описанию контекста?
• Что если мы переместим эту возможность за пределы контекста?

Начните определять возможности, представив публичный интерфейс. Что потребители могут запрашивать у этого bounded context и какие команды они могут вызывать? Используйте потоки доменных данных, чтобы увидеть, что нужно потребителям от этого bounded context.

Не все возможности активируются командами и запросами извне. Некоторые возможности могут запускаться изнутри. Например, запланированные задачи. Иногда вы можете заметить, что возможности объединяются в кластер, например, команда, запрос и уведомление. Если это так, соберите их вместе на канвасе и дайте кластеру имя.

У вас может появиться ощущение, что ответственность неуместна и должна относиться к другому bounded context. Если это так, выделите его с помощью какого-то опознавательного знака на стикере.

Следующие шаги

Если вам трудно определить возможности контекста или вы чувствуете, что некоторые из них отсутствуют, я рекомендую вернуться к EventStorming и более подробно смоделировать этот bounded context с фокусом на поиск возможностей, необходимых для других контекстов или служб.

Углубление возможностей [опционально]

Разложите каждую возможность на вашем канвасе на дополнительные возможности. Эта дополнительная детализация поможет находить альтернативные модели. Если на канвасе не хватает свободного места для деталей, найдите другой лист бумаги или пространство на стене. Вы можете пройти столько слоев вглубь, сколько сочтете нужным.

4.4 Зависимости

Зависимости необходимы, если мы хотим модульности, но они же вызывают широкий спектр бизнесовых, технических и социальных проблем. Поэтому важно видеть зависимости, понимать их влияние и учитывать альтернативные варианты. И поэтому последний шаг проектирования bounded context направлен на то, чтобы вы зафиксировали все ключевые зависимости вашего bounded context.

Просматривая результат EventStorming и диаграммы потоков доменных данных, определите каждую зависимость, которую имеет bounded context, и запишите следующую информацию:

• название другого bounded context или службы;
• краткое объяснение, почему существует зависимость;
• где находится зависимость: внутри этой системы или во внешней системе (например, сторонний сервис);
• тип отношения: это входящая зависимость (другой сервис зависит от этого bounded context), исходящий (этот bounded context зависит от другого), двунаправленный или пользовательский интерфейс (зависимость — это некоторый тип пользовательского интерфейса).

Поставьте под сомнение каждую из зависимостей: нужна ли она, каковы затраты и преимущества от ее наличия. Если покажется, что без неё можно обойтись, пометьте зависимость желтым стикером.

4.5 Конструктивная критика

Когда вы завершили заполнение канваса, потратьте несколько минут на то, чтобы критически оценить полученный дизайн вашего bounded context. Разбейте свои отзывы по следующим категориям:

• Хорошо: аспекты дизайна, которые вам нравятся.
• Плохо: аспекты дизайна, который вам не нравится.
• Не уверены: аспекты дизайна, в которых вы не уверены.

4.6. Рефлексия и повтор

Хороший дизайн итеративен. Прежде чем перейти к следующему bounded context, отойдите назад и посмотрите на общую картину. Вы узнали что-нибудь, что противоречит вашему дизайну? Если да, то перечертите предложенные границы, а затем продолжайте проектировать следующий bounded context.

На этом этапе спросите себя, достаточно ли подробно смоделирован домен. Было ли сложно заполнять какие-то части канваса? Если это так, попробуйте провести еще один раунд EventStorming по всему домену или в каких-то отдельных его частях.

5. Создание контекстных карт

После создания канваса для каждого bounded contexts и сбора обратной связи по дизайну, следующая часть сессии — это возвращение к исследованию. На этот раз у вас есть полный набор знаний, которые помогут найти лучшие варианты дизайна.

Результатом этого упражнения является коллекция базовых контекстных карт — визуализаций структурных взаимосвязей между bounded contexts и любые другие диаграммы, которые вы считаете необходимыми, например диаграммы доменных потоков. Каждая команда должна разработать как минимум 3 контекстные карты, каждая из которых будет показывать возможные варианты построения системы.


Пример очень точной контекстной карты, для этого воркшопа ее достаточно.

Мы проведем митап на TechLead Conf 2020, на котором разберем различные приемы, паттерны и анти-паттерны применения DDD и соберем наглядный радар. Который опубликуем после конференции.

Финальную активность можно провести в свободной форме. Цель состоит в том, чтобы пересмотреть собранную информацию и использовать ее для разработки некоторого количества дизайнов системы. В качестве отправной точки я рекомендую:

• Просмотреть все отзывы, собранные для каждого контекста, и поэкспериментировать с «плохими» и «неуверенными» отзывами.
• Задать вопросы «что если» ...
• «Что если мы перенесем эту возможность в другой bounded context?»
• «Что если мы разобьем эту возможность и переместим одну из подфункций в другой bounded context?»
• «Что если мы разделим bounded context на несколько контекстов?»
• «Что если мы возьмем возможность из каждого из этих трех контекстов и используем ее в новом контексте?»
• «Что если мы продублируем функциональность, чтобы убрать зависимость?»
• «Что если мы создадим общий сервис, чтобы уменьшить дублирование в разных контекстах?»
• «Что если мы изолируем действительно ключевые возможности и переместим остальные в более спокойное место, в отдельный контекст?»

Если вы предпочитаете визуализацию этих преобразований, вам могут быть полезны следующие иллюстрации:

Закрытие воркшопа

Чтобы завершить сессию, каждая группа должна представить подборку созданных ими контекстных карт и обсудить компромиссные моменты каждого дизайна. Нужно объяснить свой выбор, для этого обычно достаточно презентации на 5-10 минут.

Что нужно учесть в презентации:

• Сосредоточьтесь на ключевых областях: как каждый вариант дизайна позволяет более эффективно разрабатывать основные части системы.
• Сравните диаграммы потока доменных данных: как дизайн одной системы уменьшает сложность и количество зависимостей.
• Объясните, что вы будете делать дальше, чтобы проверить свой выбор.

Онлайн-конференция TechLead Conf состоится 8 и 9 июня и будет полностью посвящена инженерным процессам и практикам. Через 32 доклада, митапы и воркшопы мы обсудим главные задачи техлидов, разберем реальные кейсы внедрения инженерных практик в компаниях, составим матрицу зрелости техлида, подготовим техрадар по DDD и разберемся в наличии пользы или вреда с появлением платформенных команд в компании.

У онлайн-формата есть неоспоримое преимущество — это намного дешевле (и по цене билетов, и потому что не обязательно полностью выпадать из рабочего процесса на несколько дней). Поэтому приглашаем всех, кому небезразлично качество технических решений.