Так выглядит моя полка

Секреты низкой продуктивности

В 2021 году становится все сложнее сохранить низкую продуктивность. Как это сделать - помогут пять простых советов:

1. Постоянно встречайтесь с кем-то вместо того, чтобы решать всё на онлайн звонках. Это позволит вместо получаса тратить по часу-полутора на каждую встречу, плюс час между ними на разные передвижения, перемещения и просто свободные окна. В результате вы сможете сократить количество полезных разговоров в 3-4 раза!

2. Откажитесь от быстрых транзакций в онлайне и через крипту - передавайте деньги наличными, выставляйте счета, пусть Галочка сделает перевод в банковские часы. Ни к чему отправлять тысячу долларов с телефона с карты на карту - лучше встретится в конце недели и вместе выпить чаю.

3. Старайтесь заниматься всеми делами с телефона, маленький экран поможет тратить побольше времени на чтение разных материалов. А уж как маленький экран помогает медленно печатать!

4. Постарайтесь не делать никаких заметок, которые могут позволить вам лучше понять какую-то информацию, запомнить события или узнать себя. Лучше каждый день начинать с чистого листа, а всё важное вспоминать по ситуации.

5. Не пользуйтесь гуглом, пусть вам лучше кто-нибудь всё объяснит так, как он это видит. Вообще, старайтесь перелопачивать поменьше информации, полагаясь на мнение одного-двух человек, желательно случайных.

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

Ориентация на продукт/проект

MSA декларирует ориентацию на продукт (принцип Products not Projects)
В разговоре с коллегами - полное непонимание.
Максимум, что вспоминают - это наличие не человека DevOps-а.

В моём упрощенном и поэтому несколько ущербном представлении:
- Ориентация на проект - это ориентация на выполнение задач,
- Ориентация на продукт- это возможность (can, may) эти задачи ставить.

Если задачи приходят от ПО - команду ориентируют на проект.
Если от ПО приходят истории - а команды перекладывает их в задачи - ориентация на продукт.

Если инциденты приходят от службы эксплуатации - процесс.
Если служба эксплуатации часть команды - продукт (привет DevOps!).

И самое интересное с архитектором.

Архитектор вне команды - процесс.
Архитектор в команде (ArcOps, DevArcOps) -> архитектурный бэклог (enablers) внутри команды - продукт.

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

Откуда берутся задачи для арх. кома ?
Ставит ГЛАВНЫЙ архитектор - процесс
Ставит команда (архитектура как сервис) - продукт.

"Главный" архитектор - в роли арбитра и последней инстанции
но без прав и власти (не дает задачи). Хм

Чувствую, тут не всё так однозначно

Завтра веду курс "Современные сервисные архитектуры"
Хочу часть опросов проводить на этом канале
С целью накопления статистики

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

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