Последние пару недель мы начали экспериментировать с форматом контента.

Если раньше чаще были карточки с теоретической информацией, то сейчас стали добавлять больше настоящих рабочих кейсов аналитиков.

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

— как правильно проектировать интеграции;
— где узкое место в архитектуре;
— почему решение выглядит логичным, но создаёт проблемы в проде;
— какие варианты реально используются в компаниях.

Интересно понять, как вы это ощущаете 🙂

📌 Границы сервисов

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


👉 Зачем думать о границах:

Не "нарисовать 12 блоков", а ответить: какой сервис за что отвечает и какие данные ему принадлежат.

Хорошая граница:
▫️ Совпадает с бизнес-возможностью (заказ, оплата, доставка)
▫️ Имеет свой жизненный цикл данных — другие сервисы не лезут в чужую БД
▫️ Меняется относительно независимо: можно выкатить оплату, не трогая каталог


👉 Как искать границы на практике:

1️⃣ По процессу — шаги бизнес-процесса → кандидаты в сервисы (но не каждый шаг = сервис)
2️⃣ По данным — у кого «источник правды» для сущности? Заказ живёт в Order Service, не в Payment
3️⃣ По нагрузке и НФТ — если расчёт ETA тормозит всё, его можно вынести, не дробя монолит на 20 частей
4️⃣ По команде — Conway's law: структура системы повторяет структуру коммуникации команд


👉 Красные флаги плохого разбиения:

▫️ Два сервиса пишут в одну таблицу
▫️ Синхронная цепочка из 5+ вызовов на каждый клик пользователя
▫️ "Общая" БД с JOIN-ами между доменами — признак того, что граница проведена на схеме, а не в голове


💡 На Middle от аналитика ждут не определение DDD, а умение объяснить: "Мы выделили сервис оплаты, потому что у него отдельный SLA, PCI-ограничения и свой релизный цикл".

📰 Новости | Роль аналитика в эпоху ИИ, как пересобрать архитектуру

Forrester выпустил отчёт «Rearchitecting Applications For The Age Of AI» — исследование о том, как ИИ меняет логику построения корпоративных систем.

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

👉 Что нового важно для системного аналитика:

▫️ Адаптивная оркестрация вместо BPM — ИИ-агенты принимают решения в рантайме. Аналитику нужно описывать не "шаг 1 → шаг 2 → шаг 3", а границы, цели и контекст, внутри которых ИИ сам выстроит траекторию.
▫️ Приложения генерируются по описанию — пользователи или агенты создают временные приложения под задачу естественным языком. Фокус смещается с проектирования статичных систем на проектирование многократно используемых бизнес-сервисов.
▫️ Контекст становится архитектурным слоем — ИИ-агентам нужны не просто данные, а их семантическое значение в реальном времени. Появляется слой управления контекстом (стандарты вроде MCP указывают, как он может развиваться).

👉 Что это значит на проекте:

- Уходит слой Experience API — теперь ИИ-агент будет адаптировать бизнес-логику под интерфейс (мобилка/веб/чат) напрямую, обращаясь к Business API.
- Новые требования к API — ИИ плохо работает с низкоуровневыми техническими API. Нужны чёткие бизнес-сервисы, которые инкапсулируют намерение, правила и результат.
- Меняются НФТ — вместо контроля каждого пути проектируем безопасные границы (guardrails), внутри которых ИИ-агент действует автономно.

💡 Для собеседования: если спрашивают «как изменится роль аналитика через 2–3 года», уверенный ответ уровня Senior — смещение фокуса с линейных UX-потоков на проектирование бизнес-возможностей, границ оркестрации и семантического слоя данных.

Источник: Forrester «Rearchitecting Applications For The Age Of AI»

📂 Кейс: Saga вместо распределённой транзакции — когда "откатить всё" невозможно

🏢 Контекст:

B2B-портал закупок. Заказ проходит: резерв на складе → списание лимита бюджета → создание счёта в ERP → уведомление поставщику. Четыре разных системы, у ERP нет двухфазного commit. Команда 12 человек, монолит режут на сервисы.


😬 Проблема:

После выноса "Склад" и "Бюджет" в отдельные сервисы поймали баг: лимит списали, ERP вернула 500 — заказ завис "в полупути". Ручные откаты в саппорте — 2–3 раза в неделю. Бизнес: "Нужна атомарность как в старом монолите".


🔍 Что сделал аналитик:

1. Нарисовал happy path и точки отказа — где уже нельзя просто DELETE
2. Выбрал оркестрацию Saga (центральный Order Orchestrator), а не хореографию: процесс линейный, мало автономных реакций, нужна видимость статуса для саппорта
3. Описал компенсирующие транзакции:
— Отмена резерва на складе
— Возврат лимита бюджета
— Аннулирование черновика счёта в ERP (отдельный API)
4. Зафиксировал идемпотентность шагов по order_id + step_id — повтор после таймаута не дублирует списание
5. В ТЗ добавил статусы заказа: PENDING_BUDGET → PENDING_ERP → CONFIRMED / COMPENSATING / FAILED


✅ Результат:

За 6 недель — orchestrator на state machine, дашборд "застрявших" саг. Ручных откатов — 0 за два месяца. Бизнес принял, что при падении ERP заказ может минуту быть в COMPENSATING, но не «зависнуть навсегда».


💡 Выводы:

▫️ Распределённая транзакция 2PC в микросервисах — редкость; Saga + компенсации — рабочая модель
▫️ Оркестрация vs хореография — не религия, а наблюдаемость и сложность процесса
▫️ Аналитик обязан описать что откатываем и в каком порядке, иначе разработчики напишут "retry" и забудут