Найти в Дзене
Записки архитектора

EVENT STORMING #2 Preconditions. Единый язык.

Статьи о практике так же будут разделены на два логических блока. Как бы не хотелось описать практический пример применения ES, сначала надо договорится о понятиях, без которых Event Storming не запустится ну или будет бесполезным. Гипотеза лингвистической относительности, или гипотеза Сепира — Уорфа, утверждает, что структура языка влияет на мировосприятие и воззрения его носителей, а также на их когнитивные процессы. Если вы возьмете любой комплексный материал по DDD, то на построение и важность единого языка будет сделан чуть ли не основной упор. Общий, строгий язык, определяющий однозначное трактование понятий помогающий коммуникации между экспертами предметной области( бизнес-экспертами) и разработчиками программного обеспечения. Язык структурирован вокруг модели проектной области и используется всеми членами команды. Определения бизнес сущностей, событий и так далее не могут носить локальный характер, например, использоваться только программистами или только бизнес-экспертами, о
Оглавление

Статьи о практике так же будут разделены на два логических блока. Как бы не хотелось описать практический пример применения ES, сначала надо договорится о понятиях, без которых Event Storming не запустится ну или будет бесполезным.

Единый язык.

Гипотеза лингвистической относительности, или гипотеза Сепира — Уорфа, утверждает, что структура языка влияет на мировосприятие и воззрения его носителей, а также на их когнитивные процессы.

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

Что такое единый язык?

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

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

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

Проявление последствий использования.

  • Все участвующие лица разделяют определения терминов.
  • Отсутствие необходимости в трансляции бизнесового языка на технический и обратно.
  • Органически код и архитектура стремятся к структуре бизнеса.
  • Изучение кода ведет к пониманию бизнеса и наоборот.

Критерии единого языка.

  • Однозначные и разделяемые всеми определения терминов.
  • Стремится к использование бизнес-терминов, не технических.
  • Избегает суррогатных сущностей вызванных технической необходимостью.
  • Развивается со временем.

Формирование единого языка.

Касаться практик и примеров формирования общего языка я касаться не буду. Подробнее описал Эванс и Вон Вернон.

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

Глоссарий.

Есть простые правила и ограничения реализации единого языка, что следует использовать:

Существительные - описывают сущности

  • Содержат определения
  • Кто использует

Глаголы - события.

  • Содержат определения
  • Кто использует.

Может быть расширен ролями и командами, но это усложняет мета-модель языка и усложняет поддержание его в актуальном состоянии.

Усложнять легко..

Используется в:

  • Требования: описании бизнес сценариев и пользовательских историях.
  • Архитектура и дизайн компонентов и ИС.
  • Код, тестовые сценарии.
  • Общение и встречи.

Так же, используется в документации, в том числе и пользовательской.

Сложности и ограничения.

Изменение бизнес логики.

Как бороться: вносить изменения в глоссарий.

Компромисс между детализацией и сложностью.

Как бороться:

  • Первоначально выбирать максимально простую модель глоссария. Усложнять (вводить новые сущности) только в случае критической необходимости.
  • Вводить примеры.

Многообразие терминов. В том числе и на разном уровне команд.

Как бороться:

  • Вводить понятие синонимов и трансляцию.
  • Вводить объединение терминов.

Коммуникационный барьер. Может возникать у людей с разным опытом, из разных областей бизнеса или даже из разных подразделений. Нужно помнить, что борьба с коммуникационным барьером необходима, так как здесь и сейчас вы реализуете единое решение.

Как бороться:

  • Визуализация для описания сложных концепций.
  • Обучение языку, консультации по требованию.
  • ВЫБОР ОДНОГО РАБОЧЕГО ЯЗЫКА

Сложность внедрения языка.

Как бороться:

  • Онбординг в разных доменах.
  • Обучение использованию концепции единого языка.