#архитектура
Несколько критериев, когда стоит выделять часть системы в отдельный микросервис компонент.
https://tanzu.vmware.com/content/blog/should-that-be-a-microservice-keep-these-six-factors-in-mind

Multiple Rates of Change
Когда частота изменений в нескольких компонентах существенно отличается.

Independent Life Cycles
Возникает потребность в отдельной кодовой базе, подходах к тестированию, ci/cd пайплайне.

Independent Scalability
Компоненты имеют разные требования по производительности и сценарии масштабирования. Например, админка мерчанта и ядро процессинга.

Isolated Failure
Когда нужно защитить часть системы от отказов со стороны внешних или внутренних компонентов. Например, научиться выживать при недоступности платежного сервиса.

Simplify Interactions with External Dependencies
Выделение компонентов для взаимодействия с внешними сервисами или системами. Например, чтобы уметь безболезненно переключиться на другой платежный сервис.
Так и не понял, чем принципиально отличается от предыдущего - выглядит как частный случай.

The Freedom to Choose the Right Tech for the Job
Если нужно использовать другой технологический стек для решения какой-то задачи.

#архитектура #брокеры #интеграция
Огненный выпуск об очередях. От самых простых концепций до внутренней реализации. Что внутри:
• базовые понятия на пальцах
• паттерны использования, виды брокеров, главный архитектурный выбор при использовании
• основные факапы при использовании очередей
• тестирование, масштабирование, нагрукза и внутреннее устройство брокеров

#оффтоп #манагерское
«Программист, который говорит, что «бизнес меня не касается, я только кодить хочу», – это не программист, это живой компилятор. Дизайнер, который работает только с готовыми макетами от аналитика, – это не дизайнер, это разукрашиватель формочек. И наконец, менеджер, который жалуется на невнятности задач и выгорает от неопределенности целей, – это не менеджер, это плагин к жире».

Аналитик, который жалуется на изменение/отсутствие требований - …?

Оригинал: https://t.me/toxic_manager/224

#продуктовое
Полезный ресурс для тех, кто проектирует онбординг пользователей или отвечает за него: https://www.useronboard.com

Внутри сценарии онбординга популярных сервисов с разборами и комментами, плюс набор UX-шаблонов.

#оффтоп
- Кто такой бизнес-архитектор?
- Это бизнес-аналитик, который не влезает в вилку

#архитектура
Как-то писал про лекции Бунина по проектированию хайлоад решений. Так вот, если не нравится смотреть лекции, то похожий курс есть в виде бесплатной рассылки: https://highload.guide.

Внутри 30 статей, собраны из материалов HighLoad++. Хорошо для знакомства с темой и неспешных размышлений о прочитанном.

А тут исходный пост.

#события #анализ
Если кто-то хочет попрактиковаться в EventStorming, то есть отличная новость: 29 сентября Сергей Баранов и Systems.Education проводят практический воркшоп на тему.

Ходил пару лет назад на воркшоп Сергея, было огонь-огонь, отличный вариант для быстрого старта.
https://sysanschool.timepad.ru/event/2175451/

#API #архитектура

Еще одна серия холивара REST vs RPC. В прошлый раз защищали JSON-RPC, теперь REST.
Автор смотрит с точки зрения архитектуры, рассматривая вопросы:
⁃ batch-операции против атомарных
⁃ использование HTTP-инфраструктуры
⁃ управление транзакциями на разных компонентах

И снова #реклама и #продуктовое

Летом проходил курс Ани, зашло отлично. Имхо, отличный способ въехать в тему для начинающих, и возможность попрактиковаться на кейсе для миддлов.

https://t.me/product_weekdays/300

#продуктовое #анализ #карьера

Заметка об особенностях работы продакта в b2b.
Многие тезисы пробуждают воспоминания о заказной разработке. И что характерно, автор выделяет отличный от b2c скиллсет:

“Как правило от продакта в b2b ожидают следующие навыки: бизнес-анализ, системный анализ, проектный менеджмент. Собственно, это минимум, который позволит полноценно управлять продуктом. Именно поэтому чаще всего b2b-продактами становятся бывшие системные и бизнес аналитики, а также менеджеры проектов"

“Для продактов из b2b бОльшую ценность несут конференции по системной аналитике, нежели продуктовые конференции. Большая часть того о чём говорят на продуктовых конференция просто не пригодится, а ощущение, что что-то с твоим продуктом (или карьерой) не так может остаться"

#оффтоп
Истинная мощь BPMN

#архитектура

Некоторые ошибки-проблемы, которые вылезают при переходе на событийную архитектуру, и как с этим жить: https://theboreddev.com/common-mistakes-in-event-driven-systems/
Внутри несколько годных ссылок.

1. Обеспечение порядка отправки и обработки событий. Эта тема хорошо освещалась в видео: https://t.me/another_sa/46
2. Атомарность операций и согласованность данных
3. Параллельная отправка множественных сообщений
4. Изменение содержимого событий без обратной совместимости

Кстати, на грядущем AD намечается доклад про EDA для глазами аналитиков: https://analystdays.ru/ru/talk/102798 - возможно, будет интересно.

#архитектура
Развивая тему событийной архитектуры, более глубокая статья о возможных проблемах при переходе на нее.

Здесь уже обсуждают использование event sourcing, размер сообщений, поддержка и отладка системы в целом, идемпотентность при обработке событий.

#архитектура #интеграция #API

Ребята из Apollo собрали 10 принципов проектирования GraphQL-сервисов.

По мне это скорее список подводных камней, о которых обязательно нужно думать при использовании GraphQL. Для каждой проблемы авторы приводят идеи, что нужно делать, но не как это делать. В этом смысле очень похоже на книгу о мкиросервисах Ньюмана. Но все равно хороший чек-лист, о чем стоит задуматься.

Хотя одно решение предлагают: используйте линейку Apollo))

#оффтоп #карьера
Посчитал, что за почти два года провел 10 курсов и интенсивов. В каждом потоке были участники, с которыми продолжаю общаться или пересекаюсь временами. Характерно, что все, у кого получается использовать скиллы и инфу с курсов на практике, еще до обучения активно изучали информацию по книгам, ютубу и другим источникам. Да и сейчас продолжают это делать.

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

И что делать? Прежде чем платить за обучение, имеет смысл взять какой-нибудь открытый мини-курс, цикл лекций или книгу, которые можно последовательно использовать на работе, пет-проекте или учебном примере. Так можно выработать привычку регулярно учиться - необходимый скилл в современной итшечке. Или мире? Заодно появится большее понимание, что нужно от платного обучения и как его выбрать.

А если ничего не получается, и тема совсем не заходит, может ну его, этот анализ/разработку/менеджмент?