Записки системного архитектора

Мне жена как-то сказала, что только в зрелом возрасте осознала трагедию сказки о рыбаке и рыбке.

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

Старуха, услышав такое, дар речи потеряла. Напомню, они 30 гаком лет живут они в грязной землянке, в бедности и отчаянии, никаких просветов на горизонте. А ему, видите ли, и не надо ничего! Говорит она ему в сердцах: ну ты вообще разум потерял что ли? Ничего, говоришь, тебе не надо? Блин, да хоть корыто попросил бы!
Старик послушал, и что сделал? Он пошёл и попросил корыто!
И тут уж бабку разорвало и понесло..
Короче, нет повести печальнее на свете, чем повесть о попытках мужчины угадать желание женщины...

Шутки-шутками, а я эту историю вспоминаю всё чаще, когда прошу Клода сделать что-то посложнее, чем написать код. Эта железяка, безусловно, сильно умнее многих ловцов золотых рыбок, но глядя на результат его деятельности невольно ощущаешь себя старухой из сказки. Вроде говоришь ему нормальным языком - вот тебе вводные, структурируй и напиши внятный текст. Боже, какую муть оно выдаёт. Причем, все формальные признаки соблюдены, требования, условия - всё написано, предельно подробно и аккуратно. Только почему-то стыдно людям показывать. И непонятно, что надо этой железяке сказать, как её научить, чтобы результат меня устраивал. Всё таки придется самому писать, это будет быстрее, чем промт оттачивать.

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

Интересно, почему так?

Я не давлю. Я пытаюсь опереться.

Пригласили меня тут в жюри школьного проектного конкурса, и вот что хочу сказать: мало кто может сформулировать проблему.

А точнее — отличить проблему от факта.

В основном авторы проекта в качестве проблемы формулируют некий факт. "Школьники стали реже заниматься спортом". "Мало кто знает историю своего района". "В школе часто меняется расписание".

Это не проблемы, это факты. Их можно проверить. С ними ничего не происходит, это просто замеры, констатация. Возможно, это симптом или причина проблемы. Если вас это почему-то беспокоит, можно покопать и докопаться до проблемы, к которой эти факты приводят. К каждому такому факту можно задать вопрос "ну и что?", это будет шагом к определению проблемы.

Мы не можем "решить" факт. Можем как-то изменить реальность, чтобы изменились факты (произошел импакт). Но чтобы понять, в какую сторону менять — нужно сформулировать проблему.

Для школьников это нормально, они ещё учатся. Но то же самое происходит и в рабочей практике! И у аналитиков, когда они берутся за разбор какой-то темы или запроса от пользователей. "Медленно работает запрос". "У пользователей нет возможности скачивать документ с предыдущими изменениями".

Тут мы видим ещё один частый антипаттерн: формулировка через отсутствие. "Не внедрена CRM". "Отсутствует возможность сделать ...", "У школьников нет понимания ...", "Задачи по математике не привязаны к реальной жизни" и т.д. Это тоже факт. Ну да, чего-то нет. Почему это проблема? А оно вообще нужно? А почему? А кому? А зачем?

Следующая частая ошибка — формулировка не проблемы, а задачи. "Требуется реализовать возможность проверки действительности паспорта". "Сделать импорт ФИО студентов из файла". Если вы думаете, что такую фразу сложно представить, как проблему, то нет: "Проблема: оказание помощи отстающим ученикам". "Проблема: уменьшение числа заявок, введенных с ошибками".

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

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

Собственно, аналитик нужен, чтобы превратить проблему в набор задач.

(А продакт — чтобы понять, какие проблемы стоит решать)

Что должно быть в формулировке проблемы? Там должен быть разрыв.

"Наблюдается [X], а должно быть [Y], поэтому происходит [Z]"

X — это как раз наш факт. Ему обычно не хватает Y — а как должно быть? И Z — что плохого из-за этого случается?

"Школьники стали реже заниматься подвижными играми на переменах [тут должны быть данные, как раньше, и как сейчас], поэтому на последних уроках им тяжелее концентрироваться"

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

Причины потери концентрации требуют отдельного исследования, которое в реальной жизни мало кто делает. Ну вспомните, давно ли вы рисовали причинно-следственную диаграмму? Да ещё с опорой на данные, а не потому, что так всем кажется?

Следующий вопрос — чья это проблема? Кто страдает? Школьники, учителя, родители? Администрация школы, которой дадут по шапке за низкие результаты?

Итого, получается несколько проверок на формулировку проблемы:

1. В формулировке есть разрыв (можно сформулировать конструкцию XYZ,описанную выше)

2. Есть "владелец боли". Ясно, кто страдает, и понятен негативный эффект.

3. От боли нельзя отмахнуться. Понятно, что если ничего не сделать сейчас — ситуация будет ухудшаться, возникнут риски.

4. Формулировка не содержит упоминания конкретного способа решения. При прочтении непонятно, что делать.

5. В формулировке нет субъективных оценок (медленно, неудобно, сложно, непонятно, плохо).

6. Формулировка не содержит отрицания, не упоминает отсутствие чего-либо.

7. Сформулирована ровно одна проблема (нет и/или/запятых).

Зачем вообще выявлять и формулировать проблему? Почему не сразу брать в работу? Чтобы деятельность была осмысленной; чтобы решать проблемы, а не пилить задачи. Чтобы обоснованно выбирать, что делать.

Как технические границы делают все бизнес-критичным?

Ключевой вопрос, которому посвящена эта заметка: «если границы компонентов — технические, как вы определите, какие из них бизнес-критичны?»

Представьте универсальный компонент «Сервис уведомлений». Он отправляет 500 различных типов сообщений по разным каналам (sms, push, почта, мессенджер):
- С днем рождения
- С 8 марта
- Спасибо за покупку»
- ....

Среди этих 500 типов уведомлений есть одно бизнес-критичное: 161-ФЗ, статья 9.4 – «Оператор по переводу денежных средств обязан информировать клиента о совершении каждой операции с использованием электронного средства платежа путем направления клиенту соответствующего уведомления...».

Что происходит с компонентом?

Он автоматически становится бизнес-критичным. Хотя бизнес-критичного в нем – три копейки. Но теперь у него иной SLA, иной статус. Он стал «золотым» в разработке, тестировании и поддержке.

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

И самое интересное. Когда границы компонентов и границы бизнес-возможностей/бизнес-процессов, доменные границы не совпадают мы наблюдаем такую картину:

1. Есть критичный бизнес-компонент
2. Границы десяти компонентов информационной системы проведены не в соответствии с границами предметной области, а технически/как пришлось
3. От критичного бизнес-компонента в каждом техническом компоненте по 5% логики
4. Все 100% всех десяти компонентов становятся бизнес-критичными

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

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

Закончить бы хотелось отсылкой к выступлению Дениса Тимофеева. Денис упоминает «Класс критичности систем». В выступление этот пункт – часть чеклиста при передаче в эксплуатацию и хочется напомнить, что, класс критичности – это то, что распространяется на всю систему, в рамках эксплуатации и если в системе критичного 5%, то все равно, все 100% системы будут критичными, то есть в общем случае вся система унаследует класс критичности самой критичной ее части, даже если это буквально одна функция из тысячи.

Неуловимо напоминает "основной закон органической химии". Если смешать бочку мёда и бочку говна - получится две бочки говна...

(продолжение рассуждений про больницу)
Что мне тут понравилось, что беру на заметку.

1. Четкое разделение труда, понимание кто и за что отвечает. Врач делает назначение, записывает его в карту и он уверен, что назначение будет выполнено, не бегает ни за кем и не проверяет, а правильно ли отсыпали таблетки и не забыли ли сделать укол.

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

2. Память системы, вместо памяти отдельного человека. Медперсонал работает посменно, бригада медсестер меняется каждый день. Но вся важная информация, все назначения отражены в карте. Каждый пациент каждый день получает свои индивидуальные назначения, независимо от того, кто именно сейчас на смене.

3. Относительная независимость подсистем, связанность через четкие "контракты" - назначения врачей расползаются по другим подсистемам по понятным, отлаженным каналам.

Это дает возможности, например развития отдельных подсистем без влияния на другие: новые средства уборки, замена оборудования в процедурных, обучение врачей. Впрочем, зависимость между подсистемами, безусловно, есть - исполняющие подсистемы должны быть способны выполнять назначения врачей (быть обеспечены соответствующими лекарствами, оборудованием, квалифицированным персоналом). Ну и врачи из множества возможных назначений, вероятно, выбирают те, которые отделение, как система, способно выполнить.

4. Разделение труда позволяет при случае четко идентифицировать, на каком этапе и что пошло не так и внести коррективы - заменить назначение или оборудование в процедурном кабинете.

5. Очень высокие требования к компетенциям и качеству работы на каждой роли. Никакой гениальный врач не поможет, если медсестра не умеет ставить уколы, санитарка плохо моет полы, а выданное питание не соответствует ситуации. При этом медсестра даже самой высокой категории без назначения врача шагу не сделает. У каждого своя работа и своя ответственность. Больница - это место, где, несмотря на четкое разделение труда, важна слаженность и взаимное доверие.

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

Чёткое разделение делает работу одновременно сложнее (эдакая "бразильская система", как в старом Ералаше: ты точно знаешь, что никто кроме тебя твою работу не сделает, отступать некуда, позади Москва витрина), но одновременно и проще (не нужно кидаться делать то, что не твое, ты знаешь, что всё учтено и будет сделано).

В нашей ИТ-шной реальности мы часто видим обратную картину - все сложно, непонятно, границы ответственности размыты, все хватаются за все, под вывеской командной ответственности никто до конца не отвечает ни за что. Результат предсказуем: все "в мыле", пациент в коме, а что с этим делать - непонятно.

В следующий раз, когда будете организовывать команду или проект, попробуйте нарисовать подобную структуру вашей деятельности - кто "диагноз ставит" (принимает решения), кто "назначения выполняет" (реализует), кто за какой результат отвечает. И главное - как информация передается между ролями, чтобы ничего не потерялось. Это непросто, но очень полезно.

P.S. Я тут декомпозировал деятельность только одного отделения вокруг одного пациента, а в масштабах больницы всё, наверное, сильно сложнее и гораздо интереснее. Где-то там есть подсистемы выполнения анализов, а каждый кабинет типа УЗИ или рентгенографии функционирует как отдельная подсистема с входящими очередями задач. Для интересующихся для развлечения и расширения кругозора рекомендую книгу "Клиника: анатомия жизни" Артура Хейли, там интересно и живо расписана работа клиники. Книжка уже старая, но интересная.

Иллюстрация к посту.
Примерно вот такая схемка получается.

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

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

Итак, для простоты пропустим приёмное отделение и посмотрим, как устроена жизнь в стационаре. Я выделил вот такие подсистемы:
💊 Подсистема лечения - самая главная часть, вокруг которой крутится всё остальное. Делает так, чтобы каждый пациент получил правильный диагноз и правильное лечение. Тут работают врачи и ординаторы, они выполняют первичный и регулярный осмотр пациентов, составляют план лечения и выдают назначения - что должно быть сделано (анализы, исследования, лекарства, процедуры, выписка и т.п.). Назначения записываются в карту пациента и доступны другим подсистемам на чтение.

👉 Подсистема выполнения назначений, её функция в том, чтобы каждый пациент получал то, что должен получить и не получал того, что не должен. Тут первыми стоят медсестры на посту отделения. Они каждый день берут составленные врачами назначения и формируют листочки-директивы для разных подсистем:
1. Кого и в какой кабинет направить/проводить. Листочки с инструкциями раздаются пациентам, дальше они идут ногами. Кто не может ходить сам - того возят санитары.
2. Кому какая диета показана, этот листочек идет в подсистему обеспечения питания.
3. Кому какие лекарства и в каком виде. Список уколов и капельниц передается в процедурный кабинет. Таблетки раскладываются в таблетницы и медсестры разносят по палатам, дальнейшее исполнение назначения делегируется пациентам.
4. Кого готовить на выписку - этот листочек идет в подсистему обеспечения чистоты, там написано какие постели надо очистить и подготовить к новым пациентам.

💉 Процедурный кабинет, специальное место для выполнения процедур - уколов, капельниц, перевязок и т.п. Для меня стало открытием, что медсестры на посту и в процедурном кабинете имеют принципиально разные обязанности, это разные люди.

🍜 Подсистема обеспечения питанием. Делает так, чтобы каждый пациент получал питание, соответствующее диагнозу и состоянию. Работник службы формирует наборы питания в соответствии с назначенными диетами и развозит по палатам. И если у тебя назначен нулевой стол, то выпросить котлетку не удастся, даже если очень хочется. Ты, конечно, можешь сходить в буфет на первом этаже и сожрать всё, что душа просит, но тогда ты сам себе злобный буратино.

🧹 Подсистема обеспечения чистоты в палатах. Тут все предельно просто. Работники этой подсистемы регулярно проходят по палатам и проводят регулярную уборку, вынос мусора и т.п. Ну и перестилают постели после выписки пациентов.

Это наверняка не исчерпывающий список, наверняка есть еще, как минимум, какие-то механизмы по работе с операционными, но с ними я, к счастью, не сталкивался.

продолжение следует...

Понравилось

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

Если вы продукт менеджер:
- Без доступа к PNL
- Без доступа к метрикам
- Не понимаете как работает бизнес
- Не находитесь внутри рынка, для которого делаете продукт
- Не понимаете технических аспектов разработки

У меня для вас плохие новости.

Аналогично, если вы разработчик:
- Не умеющий задавать вопросы
- Не понимаете бизнес
- Не умеете общаться
- Читаете только Jira и Кабанчика
- Считаете, что тестировать должны куа, а деплоить ДевОпсы

То у меня для вас тоже плохие новости.

Я пишу и учу про требования не как про «документацию», а как про инструмент управления рисками.

Если требования сделаны правильно, вы можете:
— вовремя сказать go / no-go
— выбрать класс решения или вендора по делу (а не по маркетингу)
— удержать scope
— снизить риск «строим не то» и ROI<0

Что делаем за 2 недели (20 часов):
— соберём требования ровно той глубины, которая нужна вашему проекту (не больше и не меньше);
— пройдём 3 итерации: от целей/границ до критериев приёмки;
— отдельно покажу, как применять GenAI: генерация + проверки полноты/согласованности.

Февральский поток курса:
— Zoom
— 2 недели, 20 часов
— будни утро 9:00–11:00
— старт 09.02 пнд
— только 6 мест (потому что будет разбор/фидбек)

Стоимость: 60 000 ₽

———

Кому подойдёт:
— системным/бизнес-аналитикам, архитекторам, продактам и руководителям, кто отвечает за результат ИС;
— если вы сейчас выбираете решение / запускаете проект / хотите остановить «плохой» проект вовремя.

Кому НЕ подойдёт:
— если вам нужен «шаблон ТЗ» без привязки к решениям и рискам;
— если не можете участвовать в 9–11.

———

Анкета предзаписи откроется 23.01 (на 48 часов).

Если хотите — можете уже сейчас написать мне: @beskov

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

Желаю всем в новом году здоровья, счастья, интересных встреч и удивительных событий. Обязательно научиться чему-нибудь новому и забыть что-нибудь старое 😊.

С Новым Годом и до новых встреч!
🎄🎄🎄

О декомпозиции через Ограниченные Контексты

Декомпозиция - абсолютно некорректный термин, который тем не менее встречается повсеместно и потому сбивает с толку. И потом очень сложно донести то, что действительно подразумевается под связью между доменом и ограниченным контекстом в DDD.

Туда же и декомпозицию монолита на микросервисы (что тоже некорректная формулировка и подход).

Давайте разбираться.

Традиционная «декомпозиция системы» в инженерном понимании почти всегда подразумевает:
1. есть единая целостная модель системы
2. мы делим ее на части
3. части в совокупности «покрывают» целое (часто еще и без пересечений или с минимальными пересечениями)

В таком понимании:
- есть единое целое,
- есть разбиение этого целого

Внезапно, Bounded Context так не работает. И переход от монолита к микросервисам так не работает :)

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

То есть мы не делим модель на куски, мы конструируем несколько моделей, которые опираются на:
- свой лексикон (Ubiq. Language)
- свои инварианты
- свой контекст применения

То есть Ограниченные Контексты выделяются из предметной области.

Самый близкий приземленный пример - это CQRS, где есть модель, в которую данные сохраняются и есть (потенциально несколько) моделей чтения, и это часто не декомпозиция модели записи, а самостоятельные проекции данных.

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

Самому писать нет ни времени, ни сил. Буду пользоваться чужими трудами. Сергей прекрасно изложил суть ограниченных контекстов в ddd.

Собрали с новейшей 5.1 Про
свежую нейрокнигу:

Проектирование баз данных для бизнес-аналитиков

Кому
- Бизнес-аналитикам, которые:
- уже пишут требования к данным, отчётам, интеграциям;
- регулярно страдают от «не так поняли», «не то посчиталось», «надо было ещё один разрез».
- Руководителям отделов бизнес-анализа, которым нужно «подтянуть» команду в понимании данных, но не делать из них админов/архитекторов.

После прочтения аналитик перестаёт говорить «ну вы там как-нибудь в базе сделайте», и начинает:
- формулировать требования в терминах сущностей, связей, событий и состояний;
- понимать, *почему* разработчики предлагают такую структуру данных;
- предвидеть типовые грабли в отчётности и интеграциях.

Книга не про то, «как писать SQL», а *«как думать о данных так, чтобы базы данных и отчёты потом получались адекватные»*.

---

Часть I. Как бизнес превращается в данные

1. Зачем бизнес-аналитику понимать базы данных
2. От бизнес-языка к сущностям и событиям
3. Концептуальная модель для бизнес-аналитика

Часть II. Логическая модель и основы реляционного мира

4. Реляционная модель простыми словами
5. Нормализация для тех, кто не хочет знать слово «нормализация»
6. Справочники, классификаторы, иерархии

Часть III. Типовые паттерны данных бизнес-систем

7. Транзакции, документы, движения
8. Состояния и жизненные циклы
9. Баланс, срезы, накопительные показатели

Часть IV. Проектирование для аналитики и отчётности

10. От требований к отчёту к структуре данных
11. Звёздочки, снежинки и хранилища
12. Качество данных: как аналитик может его не убить

Часть V. Как писать требования, которые не стыдно дать архитектору

13. Документы, которые помогают проектировать базы данных
14. Шаблоны описания данных для требований
15. Антипаттерны в требованиях к данным

Часть VI. Кейсы: от описания бизнеса до схемы БД

16. Кейс 1: Интернет-магазин
17. Кейс 2: Подписочный сервис (SaaS)
18. Кейс 3: Операционный учёт + управленческая отчётность
19. Типовые грабли и как их обходить

Приложения

А. Чек-листы для BA
Б. Мини-справочник терминов для BA
В. Рекомендуемая литература

Скажу честно, читать и изучать некогда. Но размах, масштаб и намерения Дениса вызывают восхищение и уважение.

Недавно Саша Лучков написал в чате отличное сообщение о разнице в оценке типовых и исследовательских задач. Это навело меня на мысль, что материалы, что встречались, обычно прямолинейные - бери вот такую технику и оценивай любую задачу (что, очевидо не так) и я решил подготовить обобщенный, но практичный материал на эту тему, прошу к ознакомлению:

http://agilemindset.ru/item-estimation/

А Саше спасибо за ревью статьи 🙂

Про модель Кано

В бытность свою продуктологом я узнал, что есть такая прикольная штука - модель Кано. Японский профессор Нориаки Кано придумал её в 80-х годах для анализа лояльности и удовлетворенности клиентов продуктом. Он обнаружил, что не все фичи/характеристики одинаково полезны, и что с точки зрения влияния на лояльность клиентов их можно разложить на пять кучек.

Сейчас меня интересуют три из них:
- 🎉 Привлекательные (Attractive) — неожиданные или дополнительные функции, которые вызывают восторг при наличии, но отсутствие их не вызывает неудовольствия.
- 📈 Одномерные (One-Dimensional) — характеристики, которые прямо влияют на степень удовлетворённости: чем лучше, тем выше удовлетворение.
- 🧐 Обязательные (Must-be) — базовые характеристики, без которых продукт не приемлем, но их наличие воспринимается как должное и не повышает удовлетворённость.

Замечено, что есть тенденция постепенного переползания функций из привлекательной кучки в обязательные. Так, когда-то давным-давно наличие камеры в телефоне было дополнительной привлекательной фишкой, а сейчас телефон без камеры не воспринимается в принципе. Другой пример - группировка писем в цепочки, впервые сделанная в GMail, теперь является базовой функцией любого email-клиента. Эффект чисто психологический, что бы удивительное ни было предложено, клиенты к этому привыкают и постепенно начинают воспринимать как само собой разумеющееся.

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

Например, когда идет речь о разработке простенького микросервиса в составе большого решения, который принимает команды, скажем, по REST, сохраняет состояние в своей базенке и отправляет события в кафку, я почему-то ожидаю, что без дополнительных слов и указаний этот сервис будет:
- Реализован в концепции stateless, т.е. у него не будет своего состояния и его можно масштабировать без дополнительных приседаний
- Иметь базовый набор метрик (счетчики количества и длительности обработки запросов, обращений к БД, потребления CPU и памяти)
- Сохранять структурированные логи с атрибутом трассировки, позволяющим связать записи, относящиеся к одному запросу
- Реализовывать какие-то базовые механики устойчивости к сетевым сбоям, например Retry с переменным временем ожидания при обращениях по сети к кафке или СУБД.

Т.е. этот набор характеристик в моём восприятии уже относится к обязательным. А вот реализованный Circuit Breaker в этот набор не входит, я его воспринимаю как что-то среднее между привлекательными и одномерными характеристиками - хорошо (но не удивительно) если оно есть, но не так страшно, если его нет.

А у вас какие ожидания перешли из области удивительного в пространство обязательного?

Что archimate грядущий нам готовит... #archi #archimate

https://habr.com/ru/posts/932602/