Создание компонентной структуры продукта

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

Цели

  • Создать общее понимание дизайна системы
  • Быстро пройтись по нескольким вариантам распределения ответственности компонентов
  • Создать связь между архитектурно-значимыми требованиями и вариантами дизайна
  • Построить первый вариант или выявить потенциальные пробелы в архитектуре

План проведения

  1. Расскажите участникам о целях
  2. Зачитайте участникам первую историю
  3. Создайте карточку, представляющую пользователя
  4. Запишите пользователя вверху карточки, а ниже укажите действие, инициирующее сценарий
  5. Добавьте еще одну карточку, представляющую первый архитектурный элемент. Это элемент, с которым происходит первый контакт пользователя. Напишите название элемента вверху карточки.
    Component
  6. Развивайте диаграмму, создавая карточки с новыми элементами. Указывайте на карточках ответственности каждого элемента. Помечайте отношения между элементами на карточках. Расположите карточки в таком порядке, чтобы расположение представляло связи между элементами.
  7. С развитием дизайна, оставляйте все карточки на столе. Отодвигайте карточки в сторону, если они могут понадобиться позже, что позволит вам разглядеть и быстро оценить альтернативы
  8. Возьмите следующую историю и пройдитесь по полученной схеме дизайна. В случае необходимости — добавляйте или меняйте карточки. Попробуйте изменить предположения, касающиеся историй и посмотреть, как это повлияет на дизайн.
  9. Повторяйте шаги 4-8 до тех пор, пока не рассмотрите все истории
  10. В конце сессии запишите все полученные компоненты и назначенные им ответственности. Так же запишите все принципы проектирования, выявленные во время воркшопа

Рекомендации

  • Используйте стикеры
  • Можно рисовать картинки, не только писать текст
  • Смешивать различные уровни представления (динамика, статика и физика) — нормально, если помогает в принятии решений
  • В конце упражнения каждый элемент должен иметь как минимум одну ответственность.
  • Обсудите карточки с большим количеством ответственностей.
  • Компонент должен иметь минимально возможное количество ответственностей
  • Компонент должен иметь минимально возможное число связей

Типовые проблемы

  • Прямое изменение одним компонентов данных другого компонента. 
    Нарушение принципа инкапсуляции, снижает гибкость дизайна. Требуется дополнительный анализ границ предметной области.
  • Слишком много ответственностей. 
    Компонент сложно понять и использовать. Требуется разбиение на более мелкие компоненты.
  • Отсутствие ответственностей. 
    Компонент не несет ценности. Бывает, когда проектирование велось без учета того, как компонент будет использоваться.
  • Вводящие в заблуждение именования компонентов. 
    Название компонента должно быть коротким, емким и отражать ответственность, закрепленную за ним.

Пример: «Система планирования питания для спортсменов»

Высокоуровневый список требований

  • Просмотр базы данных рецептов
  • Добавление нового рецепта в базу данных
  • Редактирование существующего рецепта
  • Планирование курса питания

Один из множества возможных результатов:

Структура компонентов

На практике модель может иметь следующий вид:

Пример структуры компонентов

Составлено на основе описания в книге Design It! (Michael Keeling)

Share

3 комментария

  • Pingback: Зависимости между компонентами - Agile Mindset

  • Эдуард

    Май 2, 2019

    Добрый вечер.

    Статья интересная, имеет четкий практический уклон. Однако мне некоторые моменты не совсем понятны.
    1. пример не иллюстрирует все шаги методики, описанной выше. Можно ли кратко их проиллюстрировать примером? Или показать конечный вариант архитектуры?
    2. указаны функциональные требования, но совсем не указаны. нефункциональные
    3. есть ли какие-то рекомендации по наименованию компонентов? В примере присутствует компонент «база данных рецептов» и «компонент рецептов», по-моему и то, и другое обозначает одно и тоже, т.е. не отражает действия, база данных еще намекает на хранение.
    4. Карточка компонента подразумевает двустороннюю связь или одностороннюю?

    • jsergey

      Май 8, 2019

      1. Конечного варианта не существует. Методика позволяет рассмотреть множество вариантов структуры компонентов и выбрать наиболее оптимальную. Подход очень хорошо дополняет принятый в Agile подход к работе с требованиями. Например, можно построить User Story Mapping, в котором определить задачи на несколько будущих версий продукта, то есть составить дорожную карту развития. Какие-то задачи точно будут выполнены, выполнение же других мы, возможно, отложим или вообще откажемся от них. Принцип такой: строим компонентную структуру для первой версии. Затем достраиваем до второй версии (возможно — в нескольких вариантах), затем для третьего. Что для нас важно — это выделить те компоненты, которые остаются неизменными для максимального количество вариантов — это стабильные компоненты и они не должны зависеть от нестабильных. Логично, что это не единственный критерий. Однако эта практика дает возможность за короткий промежуток времени рассмотреть множество компонентных структур и совместно прийти к решению о наиболее подходящей в существующих ограничениях.
      Плюс мы можем прикинуть как примерно может развиваться компонентная структура, чтобы обоснованно принимать решение о том, куда стоит заложить чуть больше гибкости, а где сделать максимально простую реализацию.
      2. Здесь намеренно не рассматриваются атрибуты качества. Цель — именно в определение логических границ компонентов, структуры зависимостей и зон ответственности. При необходимости можно явно зафиксировать внутренние атрибуты качества, но обычно на данном этапе это не требуется.
      3. Именование исходя из предметной области (Ubiquitous Language в терминах DDD). Используем принятую в домене терминологию.
      4. Одностороннюю. Двусторонняя в такой структуре означает появление циклических зависимостей.

Добавить комментарий