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

Гибкие команды требуют

качественной коммуникации

● Визуальная информация >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”