DDD и MSA

У К. Ричардсона крайне мало информации по декомпозиции.
Всевозможные шлюзы и оркестраторы возникают у него не как результат последовательного архитектурного процесса, а как решение частных проблем.

Спешу компенсировать )

1. Анализ выводит нас на понимание домена (предметной области).
Домены связаны с бизнес возможностями.
За доменами закрепляем команду (принцип MSA)
Если границы домена и сервиса совпадают - имеем паттерн "Автономный сервис"
т.е. сервис включающий в себя и слой представления данных (UI), и слой хранения (DB)

С точки зрения сцепленности всё ОК. MSA этого достаточно. Задача решена.
Но DDD идет дальше

2. Выделяем из домена поддомены. Домен становится смысловым ядром. Поддомены - специального и общего назначения.

DDD это нужно для увеличения ясности. Ясность - основная цель DDD. MSA это не нужно. Если поддомены уползут в чужие руки, теряется скорость выхода на рынок.
Нужно преодолевать барьеры. t2m - основная цель MSA.

Тут от нас могут уйти логика представления (UI), логика бизнес процесса (оркестратор), логика контроллера (шлюз).

Производительность может потребовать вывода механизмов хранения в общую БД

Единственно неразрывными остаются данные и поведение (бизнес логика).

3. Бизнес логика тоже может дробиться на сервисы.
Резон ясность и переиспользуемость (анти-паттерн в MSA)

Один домен превращается во множество под-доменов, а те в свою очередь могут распасться на множество ограниченных контекстов и сервисов.

4. Таким образом, получаем дилемму сцепленность-ясность.
Впрочем это обычное дело в архитектуре )

Агрегация против дистилляции (сравните с БД нормализация против денормализации)

Очередной компромисс.

5. И да, можно поступить хитро. Зацепить команду за доменом и все эти сервисы, шлюзы, оркестраторы будут в одних руках. Однако всегда ли это возможно/целесообразно ?

Core Domain против Смыслового Ядра

Введя термин Core Domain Эванс умудрился запутать множество последователей.

Получается, что предметная область (домен) делится на домен и вспомогательные поддомены.

В этом плане русский перевод (Смысловое ядро) намного разумнее.

В результате дистилляции Домен усыхает до смыслового ядра.
Всё отжатое попадает в поддомены.

Предполагаю что Эванс просто напутал с порядком слов )

#DDD

Core domain
Очень полезная ссылка -

https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns-941f89446af5

#DDD

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

Архитектора в лёгком замешательстве. На форумах всё чаще можно наблюдать дискуссии о настоящем и не настоящем 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

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

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

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

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

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