Архитектура. Архитектурное решение vs дизайн

1.

Архитектура
2. Архитектурное решение vs дизайн

2.

Архитектурное решение vs дизайн
Что является архитектурным решением?
• Выбор технологии или принципа работы?
• Выбор конкретного продукта?
Разговоры об архитектуре
2

3.

Архитектурное решение. Пример
Инфа о ставках пишется в различные очереди
Разговоры об архитектуре
3

4.

Архитектурные характеристики. Пример
Инфа о ставках пишется в различные очереди
А может лучше так?
Разговоры об архитектуре
4

5.

Архитектурные характеристики. Пример
Инфа о ставках пишется в различные очереди
А может лучше так?
Контекст -> «ПОЧЕМУ гораздо важнее, чем КАК»
Разговоры об архитектуре
5

6.

Архитектурное решение vs дизайн
Компоненты + Коннекторы + Ограничения
• Компоненты (Components)
элементы вычислительной системы
• Коннекторы (Connectors)
взаимодействия между компонентами
• Ограничения (Constraints)
интерфейсы, принципы, стандарты
Разговоры об архитектуре
6

7.

Архитектурное решение vs дизайн
Дизайн
Архитектурное решение
• Декомпозиция на
компоненты
• Компонентная диаграмма,
C4, «квадратики-стрелочки»
• Логическая модель
• Использование
реляционной БД
• Вынос функционала в
библиотеку
Спецификация REST-интерфейса взаимодействия
• Выбор REST/RPC/брокер
Сиквенс-диаграмма
Физическая модель БД или классы в коде
Выбор СУБД. Выделение в коде слоя работы с БД
Описание интерфейса, сокрытие ее внутренней
реализации
Выбор Kafka vs RabbitMQ
Выбор конкретной технологии(продукта) - не архитектурное решение. ....не всегда;)
Разговоры об архитектуре
7

8.

Оценка и выбор технологии
Некоторые критерии
• Документация
• Сообщество
• Разнообразие контрибьюторов
• Кодовая база
• Активность
• Зрелость
• Стабильность
• Расширяемость
• Поддержка
• Обучение
• Поиск специалистов
• Безопасность
• Лицензирование
• Хайп
Разговоры об архитектуре
8

9.

Оценка и выбор технологии
React
Angular
VueJS
Документация
Сообщество
Контрибьюторы
Кодовая база
Активность
Зрелость
Стабильность
Расширяемость
Поддержка
Обучение
Безопасность
Лицензирование
Специалисты
Разговоры об архитектуре
9

10.

Оценка и выбор технологии
Разговоры об архитектуре
10

11.

Архитектурное решение vs дизайн
Почему “Дизайн” != “Архитектурное решение”?
Разговоры об архитектуре
Понимание через fuck up
11

12.

Архитектурное решение vs дизайн
Почему “Дизайн” != “Архитектурное решение”?
Понимание через fuck up
Не прорабатывая архитектурное решение:
• не рассматриваем альтернативы
• “я уже так делал, здесь все просто”
Разговоры об архитектуре
12

13.

Архитектурное решение vs дизайн
Почему “Дизайн” != “Архитектурное решение”?
Понимание через fuck up
Не прорабатывая архитектурное решение:
• не рассматриваем альтернативы
• “я уже так делал, здесь все просто”
• не ищем ограничения
• “сейчас накидаем таблички в БД”
Разговоры об архитектуре
13

14.

Архитектурное решение vs дизайн
Почему “Дизайн” != “Архитектурное решение”?
Понимание через fuck up
Не прорабатывая архитектурное решение:
• не рассматриваем альтернативы
• “я уже так делал, здесь все просто”
• не ищем ограничения
• “сейчас накидаем таблички в БД”
• не фиксируем контекст решения
• “у меня код самодокументируемый, можно посмотреть и понять почему”
Разговоры об архитектуре
14

15.

Архитектурное решение vs дизайн
Почему “Дизайн” != “Архитектурное решение”?
Понимание через fuck up
Не прорабатывая архитектурное решение:
• не рассматриваем альтернативы
• “я уже так делал, здесь все просто”
• не ищем ограничения
• “сейчас накидаем таблички в БД”
• не фиксируем контекст решения
• “у меня код самодокументируемый, можно посмотреть и понять почему”
• теряем знания как вся система функционирует
• “в задаче Jira написано же что нужно сделать”
Разговоры об архитектуре
15

16.

Архитектурное решение vs дизайн
Почему “Дизайн” != “Архитектурное решение”?
Понимание через fuck up
Не прорабатывая архитектурное решение:
• не рассматриваем альтернативы
• “я уже так делал, здесь все просто”
• не ищем ограничения
• “сейчас накидаем таблички в БД”
• не фиксируем контекст решения
• “у меня код самодокументируемый, можно посмотреть и понять почему”
• теряем знания как вся система функционирует
• “в задаче Jira написано же что нужно сделать”
• создаем системы, к-е потом переписываем
• “давайте использовать этот крутой фреймворк”, “PostgreSQL классно с JSON работает”
Разговоры об архитектуре
16

17.

Архитектурное решение vs дизайн
Почему “Дизайн” != “Архитектурное решение”?
Понимание через fuck up
Не прорабатывая архитектурное решение:
• не рассматриваем альтернативы
• “я уже так делал, здесь все просто”
• не ищем ограничения
• “сейчас накидаем таблички в БД”
• не фиксируем контекст решения
• “у меня код самодокументируемый, можно посмотреть и понять почему”
• теряем знания как вся система функционирует
• “в задаче Jira написано же что нужно сделать”
• создаем системы, к-е потом переписываем
• “давайте использовать этот крутой фреймворк”, “PostgreSQL классно с JSON работает”
• не проводим оценку рисков и стоимости
• “ну все понятно, давайте уже кодить”
Разговоры об архитектуре
17

18.

Архитектурное решение vs дизайн
Пример
• Компания предоставляет сервис проведения встреч онлайн (система “Балтограмм”).
• В настоящий момент, сотрудники вручную подключают услугу клиентами.
• С целью привлечения большего кол-ва клиентов, необходимо позволить им самостоятельно подключать себе услугу.
Необходим лендинг с несколькими тарифами
Прямо из лендинга переходить к оплате онлайн.
После оплаты активация услуги должна выполняться автоматически.
Система предоставляет REST API для управления услугами.
Отображение статуса оплаты в личном кабинете пока не требуется.
Лендинг загружается через мобильное приложение или на десктопе. После авторизации.
• Запустить за 1 неделю
Разговоры об архитектуре
18

19.

Архитектурное решение vs дизайн
Решения принимаются:
• В традиционном подходе – на начальном этапе, до написания кода
• В эволюционном подходе – как можно позже, в последний момент, когда это еще допустимо:
• Может быть доступна дополнительная инфа
• Могут возникнуть доп. затраты на доработку
Что решаем раньше:
• модели и ограниченные контексты (Bounded Context)
• разделение на компоненты
• способ взаимодействия
Что может быть отложено:
выбор фреймворка, СУБД, брокера
способы взаимодействия
SPA или Server Side
и т.д.
Но даже выбрав неоптимальный компонент, архитектура должна иметь возможность его простой замены:
• абстракция в коде работы с “внешним” миром
• разделение все области знаний на ограниченные контексты (Bounded Context)
Разговоры об архитектуре
19

20.

Архитектурное решение vs дизайн
• Архитектурное решение направляет команду
разработки к выбору правильного технического
решения
• Решения не работают, если процесс
односторонний: от архитектора к
разработчикам
Разговоры об архитектуре
20

21.

Антипаттерные архитектурных решений
• Аналитический паралич – очень долгий анализ без принятия решения
• День сурка – никто не знает почему было принято решение и его обсуждают снова и снова
• решение не зафиксировано и не согласовано со всеми заинтересованными сторонами
• Email-Driven Архитектура – потеря или даже незнание, что решение было принято
• не фиксировать решение в теле письма
Разговоры об архитектуре
21

22.

Итого
• Архитектурное решение - это как делать не надо, это выбор наименее плохого решения
• Архитектура прорабатывается на начальной стадии, когда много неизвестных
• Дизайн выполняется когда основные неопределенности сняты
• Сравнение по критериям
• Proof of Concept
• Архитектурное решение включает:
Описание задачи/проблемы
Контекст
Принятое решение
Последствия (ограничения, что будет работать, что не будет, что будет изменено)
• Архитектурное решение - архитектор, Дизайн - команда разработки
• Командная работа архитектора и разработчиков
• ПОЧЕМУ важнее чем КАК
Разговоры об архитектуре
22

23.

Материалы
• Как поделить архитектуру и реализацию и не поругаться
• Книга “Fundamentals of Software Architecture” Chapter 2. Architectural Thinking
• Книга “Thinking Architecturally” Chapter 4. Evaluting and Choosing Technologies
• Шаблоны ADR:
Architecture decision record (ADR)
Decision record template by Michael Nygard
Decision record template by Jeff Tyree and Art Akerman
Decision record template for Alexandrian pattern
Разговоры об архитектуре
23

24.

Архитектурное решение vs дизайн
Пример
• Компания предоставляет сервис проведения встреч онлайн (система “Балтограмм”).
• В настоящий момент, сотрудники вручную подключают услугу клиентами.
• С целью привлечения большего кол-ва клиентов, необходимо позволить им самостоятельно подключать себе услугу.
Необходим лендинг с несколькими тарифами
Прямо из лендинга переходить к оплате онлайн.
После оплаты активация услуги должна выполняться автоматически.
Система предоставляет REST API для управления услугами.
Отображение статуса оплаты в личном кабинете.
Лендинг загружается через мобильное приложение или на десктопе. После авторизации.
Отправка уведомлений по смс и/или эл. почте
Возможность отключение услуги в личном кабинете
Возможность продления подписки (оплата за следующий период)
• Особенности системы
• Время активации услуги в системе в среднем 10 минут.
Разговоры об архитектуре
24