Архитектоника в ИТ

Признак нарушения архитектурных границ: чужой ID

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

Контекст

Конкретный пример.

Врач завершает осмотр и назначает следующий визит. Бэк мобильного приложения (BFF) сохраняет протокол осмотра и вызывает сервис задач. Тот бронирует время в календаре врачей и создаёт задачу на следующий визит.

Затем BFF вызывает сервис подтверждения записи, передавая ID протокола и ID бронирования. Подтверждение связывает бронь с состоявшимся осмотром. По правилам бизнеса такую бронь уже нельзя отменять, хотя технически это возможно.

Бронированием занимается сервис задач, а подтверждением – BFF. Поэтому сервис задач вынужден вернуть клиенту ID, полученный от календаря.

Проблема

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

Чем это грозит?

⚠️ Излишняя связанность. BFF участвует в бизнес-процессе, часть которого скрыта внутри сервиса задач. Стоит проверить, обосновано ли такое разделение ответственности.

⚠️ Хрупкость контракта. При замене календаря могут измениться формат и смысл ID. Тогда изменения затронут всех его потребителей.

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

Выявление проблемы

Признак нарушения границ:

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

Признак удобен при проведении ревью и подталкивает к обсуждению вопросов ответственности и стоимости будущих изменений:

▫️ Откуда пришёл ID?
▫️ Зачем он потребителю?
▫️ Является ли ID частью общесистемного контракта?

Это согласуется с идеей защищать потребителей от изменений за стабильным контрактом.

Варианты решения

Вариантов много, вот основные:

▫️ Оркестратор. Отвечает за завершение всего сценария и обработку частичных сбоев. Опционально: передать подтверждение сервису задач, если весь сценарий входит в его ответственность, тогда BFF получает результат без ID календаря.

▫️ Собственный ID. Сервис задач хранит соответствие между своим ID и ID календаря. Это отделяет публичный контракт от идентификаторов зависимости. Однако придётся адаптировать подтверждение: оно пока ожидает ID календаря. Обход сервиса задач потребует специально "добывать" исходный ID и строить отдельную интеграцию. Это усложняет и удорожает обход, вызывает вопросы при реализации и помогает удерживать границу. Но не заменяет контроль доступа.

▫️ Контроль доступа. Ограничить изменение броней, созданных сервисом задач, разрешёнными участниками процесса. Отдельно обеспечить проверку бизнес-запрета отмены подтверждённой брони. Это ограничивает обходные изменения, но требует настройки прав и специфичных проверок; зависимость публичного контракта от календаря остаётся.

▫️ Общесистемный контракт. Осознанно оставить ID календаря в API, договорившись о его смысле, стабильности и правилах изменения броней. Меньше переделок сейчас, но сильнее связанность.

Как выбрать

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

Раскрытие детали реализации может стать практически необратимым решением: если другие команды построят на ней свои процессы, убрать её без их согласия и миграции уже не получится!

Короче, старайтесь не выносить сор из избы 😃

#tip #arch

Показатели эффективности работы

Все показатели зелёные, а проблемы остались. Как так?

Сотрудник укладывается в сроки, потому что регулярно работает по вечерам. Персональная метрика в норме, премия сохранена. Только планирование лучше не стало, а переработки теперь ещё и скрыты. Получилось измеримое неизвестное.

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

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

1️⃣ Проектируем механизм

"Нужно точнее оценивать задачи" – понятное пожелание. Но в основе изменения должна быть гипотеза с чёткой формулировкой: если – то – потому что.

Согласитесь, что это слабая гипотеза: "Если установить лимит на Estimate Time, то планирование станет точней, потому что сотрудники начнут делать декомпозицию задач, лучше продумывая детали реализации". Лимит может подтолкнуть к размышлениям, но скорей научит дробить задачи для прохождения формальной проверки. Неопределённость при этом останется.

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

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

Вторая гипотеза тоже может не подтвердиться! Но мы понимаем, что меняем, почему ожидаем эффект, когда и по каким показателям увидим результат или пересмотрим решение.

2️⃣ Контролируем корректность

Если разработка ускорилась, но подготовка задач стала занимать вдвое больше времени, смотрим на весь путь поставки: должен быть конвейер, а не водопад. Если количество сценариев за спринт возросло вместе с количеством багов; или потому, что спринты стали не по 2, а по 3 недели.

Любой целевой метрике нужны контр-метрики – противовесы, которые помогают увидеть перекос.

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

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

3️⃣ Подводим итоги

Для работы с метриками эффективности выделяем несколько правил:

▫️ Каждая метрика сопровождается гипотезой. Что и для чего меняем, какого эффекта ожидаем и почему.

▫️ Каждая метрика сопровождается контр-метриками. Чтобы видеть аномалии и цену результата.

▫️ Для каждой метрики определяем: текущий уровень (как точку отсчёта), целевое значение (как желаемый результат), период ожидания эффекта и период фиксации (сколько времени уровень должен удерживаться, чтобы мы считали его достигнутым, а не единичным всплеском).

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

〰️〰️〰️

Для закрепления темы предлагаю посмотреть мультфильм. 😃

// Выражаю благодарность Руслану Сафину как идейному вдохновителю для этого поста. 🔥

#view