Создание компонентной структуры продукта
Описание воркшопа по созданию компонентной структуры продукта
Воркшоп используется для обоснованного и осознанного введения в систему новых компонентов, описания ответственностей этих компонентов и как совместно компоненты формируют видение архитектуры.
Цели
- Создать общее понимание дизайна системы
- Быстро пройтись по нескольким вариантам распределения ответственности компонентов
- Создать связь между архитектурно-значимыми требованиями и вариантами дизайна
- Построить первый вариант или выявить потенциальные пробелы в архитектуре
План проведения
- Расскажите участникам о целях
- Зачитайте участникам первую историю
- Создайте карточку, представляющую пользователя
- Запишите пользователя вверху карточки, а ниже укажите действие, инициирующее сценарий
- Добавьте еще одну карточку, представляющую первый архитектурный элемент. Это элемент, с которым происходит первый контакт пользователя. Напишите название элемента вверху карточки.
- Развивайте диаграмму, создавая карточки с новыми элементами. Указывайте на карточках ответственности каждого элемента. Помечайте отношения между элементами на карточках. Расположите карточки в таком порядке, чтобы расположение представляло связи между элементами.
- С развитием дизайна, оставляйте все карточки на столе. Отодвигайте карточки в сторону, если они могут понадобиться позже, что позволит вам разглядеть и быстро оценить альтернативы
- Возьмите следующую историю и пройдитесь по полученной схеме дизайна. В случае необходимости — добавляйте или меняйте карточки. Попробуйте изменить предположения, касающиеся историй и посмотреть, как это повлияет на дизайн.
- Повторяйте шаги 4-8 до тех пор, пока не рассмотрите все истории
- В конце сессии запишите все полученные компоненты и назначенные им ответственности. Так же запишите все принципы проектирования, выявленные во время воркшопа
Рекомендации
- Используйте стикеры
- Можно рисовать картинки, не только писать текст
- Смешивать различные уровни представления (динамика, статика и физика) — нормально, если помогает в принятии решений
- В конце упражнения каждый элемент должен иметь как минимум одну ответственность.
- Обсудите карточки с большим количеством ответственностей.
- Компонент должен иметь минимально возможное количество ответственностей
- Компонент должен иметь минимально возможное число связей
Типовые проблемы
- Прямое изменение одним компонентов данных другого компонента.
Нарушение принципа инкапсуляции, снижает гибкость дизайна. Требуется дополнительный анализ границ предметной области. - Слишком много ответственностей.
Компонент сложно понять и использовать. Требуется разбиение на более мелкие компоненты. - Отсутствие ответственностей.
Компонент не несет ценности. Бывает, когда проектирование велось без учета того, как компонент будет использоваться. - Вводящие в заблуждение именования компонентов.
Название компонента должно быть коротким, емким и отражать ответственность, закрепленную за ним.
Пример: «Система планирования питания для спортсменов»
Высокоуровневый список требований
- Просмотр базы данных рецептов
- Добавление нового рецепта в базу данных
- Редактирование существующего рецепта
- Планирование курса питания
Один из множества возможных результатов:
На практике модель может иметь следующий вид:
Получить практический навык использования вы сможете на нашем тренинге, посвященном проектированию систем.
Составлено на основе описания в книге Design It! (Michael Keeling)
В 2025–2026 годах вокруг ИИ снова начался знакомый по микросервисам шум: «агенты», «оркестраторы», «мультиагентные платформы». Как и в случае с микросервисами, часть хайпа пока не подкреплена практикой. При этом под шумом есть вполне прагматичная идея: перевести ИИ из режима «умного чата» в режим «автономного участника системы», у которого есть цели, инструменты, ответственность и место в …
В эпоху глобализации технологический бизнес неизбежно сталкивается с необходимостью расширения за пределы домашнего рынка. При этом компании стоят перед архитектурным выбором: развертывать единое решение централизованно или позволить каждому рынку развиваться независимо. Рассматриваемый подход независимого развертывания представляет собой гибридную модель, которая сочетает преимущества локальной адаптации с контролируемой стандартизацией. Независимое развертывание в контексте этой статьи – это …
В статье дается ответ на вопрос, что такое Event Storming, из каких строительных блоков он состоит и как эти строительные блоки увязываются в единый процесс. Сложные системы часто разрабатывают большие группы людей, в которых мало или совсем никто не понимает предметной области проекта в целом. Каждый участник проекта знает какую-то свою часть, но собрать эти …