1. Введение
Изображение архитектуры

2. Гибкие команды требуют
качественной коммуникации
● Визуальная информация >80%
● TDD, ... не дает возможности быстро
оглядеть всю картину
● … и код тоже
● Не детальное моделирование мелочей, а
скетчи решения

3. Польза от скетчей
● Вся команда и новые участники легко
понимают общую картину
● Легко поделиться с командой, что ты
собираешься делать
● “Навигационная карта” по коду
● Пространство для анализа рисков
● Пространство для совместной работы

4. Неэффективные скетчи

5. Список технологий

6. Квадраты без линий

7. Список фич

8. Адское месиво

9. В целом всё так

10. Логический взгляд

11. Эффективные скетчи
Подход C4:
● context
● containers
● components
● classes

13. Внимание
● Принятым обозначениям и нотации
● Не стоит мешать разные уровни
абстракции между собой
● Простота
● Основанность на реальности

14. Context
● Что мы создаем?
● Кто это использует?
● Как это размещается в существующем
техническом окружении?
● Как это все взаимодействует друг с
другом?

16. Container
● Из каких служб состоит система?
● Каковы базовые технологические решения и
выбранные технологии?
● Какое распределение ответственности в системе?
● Как “контейнеры” взаимодействуют друг с другом?
● Где писать код, чтобы реализовать функционал?

18. для каждого контейнера
● Имя
● Технология
● Ответственность

19. Component
● Из каких компонентов состоит система?
● Как сгруппирована бизнес-логика?
● Понятно ли прямо сейчас, как это будет
работать, когда написан код?
● Все ли компоненты принадлежат какой-
нибудь службе?

22. Classes
UML :)

23. Еще UML
● Процессы и порядок выполнения:
Activity
● Поведение во время исполнения:
Sequence, Collaboration
● Модель предметной области:
Class, ER
● Граф состояний:
State
● Развертывание системы:
Deployment

24. Литература
● Simon Brown “Software Architecture for
Developers”