Upload
pavel-shalagin
View
71
Download
1
Embed Size (px)
Citation preview
ВведениеИзображение архитектуры
Гибкие команды требуют
качественной коммуникации
● Визуальная информация >80%
● TDD, ... не дает возможности быстро
оглядеть всю картину
● … и код тоже
● Не детальное моделирование мелочей, а
скетчи решения
Польза от скетчей
● Вся команда и новые участники легко
понимают общую картину
● Легко поделиться с командой, что ты
собираешься делать
● “Навигационная карта” по коду
● Пространство для анализа рисков
● Пространство для совместной работы
Неэффективные скетчи
Список технологий
Квадраты без линий
Список фич
Адское месиво
В целом всё так
Логический взгляд
Подход C4:
● context
● containers
● components
● classes
Эффективные скетчи
Внимание
● Принятым обозначениям и нотации
● Не стоит мешать разные уровни
абстракции между собой
● Простота
● Основанность на реальности
Context
● Что мы создаем?
● Кто это использует?
● Как это размещается в существующем
техническом окружении?
● Как это все взаимодействует друг с
другом?
Container
● Из каких служб состоит система?
● Каковы базовые технологические решения и
выбранные технологии?
● Какое распределение ответственности в системе?
● Как “контейнеры” взаимодействуют друг с другом?
● Где писать код, чтобы реализовать функционал?
для каждого контейнера
● Имя
● Технология
● Ответственность
Component
● Из каких компонентов состоит система?
● Как сгруппирована бизнес-логика?
● Понятно ли прямо сейчас, как это будет
работать, когда написан код?
● Все ли компоненты принадлежат какой-
нибудь службе?
Classes
UML :)
Еще UML● Процессы и порядок выполнения:
Activity
● Поведение во время исполнения:
Sequence, Collaboration
● Модель предметной области:
Class, ER
● Граф состояний:
State
● Развертывание системы:
Deployment
Литература
● Simon Brown “Software Architecture for
Developers”