Вынос логики из сервиса
Возможные пути

DDD vs MSA

Предполагается что MSA идеально ложится на DDD.
Многие повторяют, что MSA это DDD в распределёнке.

Однако, есть нюансы.
На картинке выше - процесс дистилляции сервиса.
Вытягиваем из сервиса всё то, что не есть логика смыслового ядра.
Это один из основных механизмов DDD

Однако, как только всё выделенное попадает в чужие руки - сразу же нарушается принцип MSA "ориентация на бизнес возможности".
Всё что связано с реализацией бизнес-возможности должно быть сцеплено вместе и отдано в руки одной команды

Либо полная хореография с прямым доступом и рендеринг на сервисе, либо три колодца.

Однако, конфликт )

#MSA, #DDD

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 от разных источников могут делегировать сложные и непонятные задачи архитектору

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