Архитектурные стили и паттерны

Архитектора в лёгком замешательстве. На форумах всё чаще можно наблюдать дискуссии о настоящем и не настоящем DDD (REST, MSA и др.)

Сами классики вносят сумятицу.

Фаулер и Левис про MSA
As with any definition that outlines common characteristics, not all microservice architectures have all the characteristics, but we do expect that most microservice architectures exhibit most characteristics.
https://martinfowler.com/articles/microservices.html

Ник Тьюн про каноническое DDD и ddd от комьюнити
https://medium.com/nick-tune-tech-strategy-blog/domain-driven-design-ddd-vs-domain-driven-design-ddd-10ec1d5ca6c7

IMHO всё встает на свои места если вспомнить старое доброе деление на стили и паттерны.

Паттерн имеет четкую цель и чёткие же нерушимые принципы построения

Стиль появляется при освоении паттерна комьюнити. Набор принципов варьируется. Выясняется, что конструкция может приносить пользу не только в рамках означенной цели. И это уже стиль.

Так было с ООП, так было с MVC. Так повторяется с новыми архитектурами.

Например микросервисы.
1. Микросервисы как паттерн (в рамках SOA) решали задачу снижения t2m и поддерживали все принципы Левиса.
2. Микросервисы как стиль - решают разные задачи (уход от надоевшего вендора ESB, организация Agile команд, независимое масштабирование и др.)
И принципы можно выбирать по вкусу. (лучше без общей БД, но можно и с ней)

Подхвачу идею Ника.
Называем паттерны с большой буквы (DDD, Микросервисы)
Называем стиль с маленькой (ddd, микросервисы )

И больше никаких споров )

EDA и MSA

Интересная книжка по смешиванию стилей

https://www.oreilly.com/library/view/building-event-driven-microservices/9781492057888/

#EDA #MSA

Получил предложение скачать бесплатно )
Если кому интересно - берите.
Легкое чтение по арх. стилям с картинками

https://get.oreilly.com/ind_software-architecture-patterns.html

Рекомендую
Очень хорошо по стратегическим паттернам DDD и топологии команд

https://www.amazon.com/Adaptive-Systems-Domain-Driven-Wardley-Topologies/dp/0137393032

Почему я больше никогда не буду использовать Паттерн Bridge

1. С паттерном Bridge я познакомился на конференции DevDaysZ.
Доклад Егора Б. "Золотой паттерн" серьёзно впечатлил. Я увидел реальную возможность улучшить свой текущий проект и решить доселе неразрешимые проблемы.
2. Мы с командой проекта "Привет Мир" запланировали внедрение паттерна и прописали его в цели очередной итерации.
3. Внедрение прошло со скрипом. В процессе мы вынуждены были отказаться от устаревшего решения со множеством классов. Остановились на простом варианте, хорошо описанном в известной статье на Хабре.
4. Что в результате? Существенное снижение производительности при вставке записей в PG. tsp упало минимум в три раза !
5. Так же пострадала надёжность. Уже на вторые сутки было обнаружено падение доступности с 99.99 до 99.5
6. Откатили всё к первоначальному варианту. Паттерн Bridge использовать не рекомендую. Сам уже точно не буду.
Пока приглядываемся к Apache Pulsar.

PS. И что это за дурацкое имя Bridge ? Специально заглянул в словарь - Bridge a card game for four players who play in pairs. Где здесь про PG ?

#сарказм

АРХКОМ

Частая тема - функции архитектурного комитета.
В случае слабосвязанных команд арх. ком решает вопросы интеграции и обмена опытом.
Тут же можно разрешать конфликты.

Попытки натянуть на арх. ком функцию оценки решений архитекторов - глупость.

Вопрос качественной архитектуры - это кадровый вопрос.

Так же как и вопрос хорошего кода.
Если над гавнокодером поставить двух начальников и заставить его писать отчеты, результат будет - гавнокод

#АРХКОМ

Веду разные курсы:
- Архитектурное проектирование при повышенных требованиях к производительности
- Архитектурное проектирование при повышенных требованиях к надежности
- Архитектурное проектирование при повышенных требованиях к безопасности

Интересно, зашёл бы курс "Архитектурное проектирование при низкой корпоративной культуре"

🖕Вопрос в продолжение выше озвученной темы.
Очень интересно, какая проблема встречается чаще всего

Закреплю ссылку на чат

https://news.1rj.ru/str/rect_arrow_chat

Презентация с моего выступления на archdays 2022

Как вписать архитектора в команду

В кулуарах конференции ArchDays 2022 обсуждали вопросы взаимодействия архитектора и команды.
Все соглашаются с тем, что команда должна участвовать в формировании архитектуры (как минимум проводить ревью).
То что у Н. Форда называется архитектура снизу.
Проблема в мотивации.
Как уговорить разработчиков участвовать в арх. процессах не формально.

Мне показался интересным опыт коллег из Райфа, которые "перевернули" процесс.

В командо-ориентированном подходе архитектура - сервис, и разработчики сами ставят задачи архитектору.

В этой модели меня смущал только один момент - разработчики часто не погружены в контекст задачи и не всегда способны увидеть все арх. риски.

Кажется что должно работать следующее решение:
1. Архитектор оценивая риски проекта описывает проблему (enablers) в форме US
2. Разработчики разгребая беклог с US от разных источников могут делегировать сложные и непонятные задачи архитектору

#АрхитектурныйПроцесс

Team topologies одним листом

System Design Interview

У меня периодически спрашивают, есть ли книжка, в которой процесс проектирования ИС рассмотрен поэтапно.
Мне кажется, что есть - https://www.amazon.com/System-Design-Interview-insiders-Second/dp/B08CMF2CQF

#bookshelf

Верификация архитектурных решений

Одна из активностей архитектурного проектирования – верификация архитектурных решений.
Верификация, в отличии от валидации, предполагает подтверждение отсутствия противоречий принятых решений в рамках системы.
Для выбора эффективных методов верификации требуется понимание того, какие противоречия в системе возможны.
Если для кода этот вопрос очевиден (код обычно противоречит требованиям), то для архитектуры отнюдь.

Попытаюсь систематизировать:
1. Архитектурное решение противоречит требованиям
Так как архитектура формируется на базе нефункциональных требований, то и противоречия стоит искать в этой среде.
a. Проверяем на проде (или стайдже), по метрикам.
В частности, так работает эволюционный подход. Попробовали - переделали
b. Строим прототип.
c. Моделируем.
Математические модели производительности или дерево отказов – могут сэкономить много средств.
В конце концов, просто проигрывая различные сценарии, можно получить массу полезной информации.
2. Архитектурное решение противоречит техническим возможностям.
Архитектура не может быть реализована
a. Передаем разработчикам и ждем обратной связи.
Возможно разработчики сразу укажут на проблемы, возможно в процессе реализации.
b. Ревью у эксперта.
c. Строим прототип.
3. Архитектурное решение противоречит различным ограничениям (юридическим, безопасности, стандартам и др.)
a. Ревью у эксперта.
4. Архитектурное решение противоречит реальным хотелкам бизнеса
a. выявляется на этапе валидации. Вне скоупа рассмотрения.

В каких случаях полезны различные варианты ревью?
Конечно же все зависит от экспертизы участников, но можно прикинуть основные варианты.
1. Ревью в процессе парного проектирования.
В основном – совместное моделирование. Прикрываем пункт 1.
2. Ревью у разработчиков.
В основном – снимаем технические ограничения. Прикрываем пункт 2.
3. Ревью у эксперта.
Прикрываем пункты 2-3
4. Обсуждение на Арх. коме.
В основном – снимаем ограничения по стандартам и т. п.
Частично прикрываем пункт 3

Каждый этап верификации стоит денег и затягивает внедрение очередных фитч.
Из предложенных стоит выбрать те, риск по которым максимален.

#ВерификацияАрхитектуры

Архитектор и управление

Часто возникают споры, должен ли архитектор заниматься управлением. Дескать, управление это удел менеджеров, а архитектор просто снимает неопределенность.

В моём понимании, архитектор, останавливающийся на этапе проектирования – недо-архитектор. Обитатель башни из слоновой кости.
Ответственность за судьбу проекта требует внедрения (проталкивания) архитектурных решений.
И тут только два пути: либо реализовывать свой проект самому, либо управлять его реализацией.
Так что, хороший архитектор занимается управлением, в самом что ни на есть «кибернетическом» смысле слова.
#управление

Власть архитектора

Для того чтобы управлять нужна власть. Власть это всегда контроль над некоторыми ресурсами.

Если вспомнить известную в узких кругах управленцев байку о морковке, управленец должен иметь контроль над морковкой.

Конечно, можно и без контроля, но в этом случае мотивация уступает место манипуляции. Крайне нестабильный кейс.

Вопрос в тему, а какой властью обладает архитектор?

#власть

Власть архитектора 2

Архитектор располагает тремя основными ресурсами:
1. Опытом. И может помочь разработчикам при решении сложных задач.
2. Знанием контекста задачи. Пока разработчики создают материальные ценности, архитектор пропитывается контекстом на различных совещаниях.
3. Ответственностью. Но здесь не раздает, а наоборот принимает на себя. Решение, которое не хочется принимать разработчику, может взгрузить на себя архитектор.

Проблема может возникнуть тогда, когда ресурсы архитектора не востребованы.

Например, слабые разработчики могут не понимать сложности задачи и не искать решений у более опытного товарища.

Вывод:
Архитектор может управлять процессом разработки только в случае наличия грамотной команды разработчиков мотивированных на реализацию проекта.
В противном случае архитектор работает в пустоту.

Коллективный архитектор

Тенденция заменить архитектора "коллективом авторов"
вызывает у меня некоторую настороженность.

Вижу следующие проблемы:
1. Размытие ответственности. В моем понимании ответвественность может быть или персональной, или никакой.
2. Фрагментация архитектурного представления системы. Целевая архитектура это прежде всего целостный ментальный образ.
Превратить это в набор терминов или лог решений можно, но эти фрагменты не заменят начального представления.
Единый ментальный образ в нескольких головах одновременно - нонсенс (Исключение Ильф и Петров).
Поэтому архитектор один, а остальные, принимая решения, должны согласовывать их с владельцем исходной картинки.