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

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

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

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

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

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

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

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