Я выбираю границы системы там, где бизнес берет на себя обязательство

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

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

Почему отделы — плохая линейка для системы

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

Гораздо устойчивее спросить: какой факт появляется в этой части работы и кто отвечает за его достоверность? Например, менеджер может подготовить коммерческое предложение, но окончательное финансовое обязательство появляется только после согласованного договора. Это разные события, даже если ими занимается один человек.

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

Три вопроса, с которых я начинаю

Где рождается обязательство? Не экран и не таблица, а конкретное действие. «Клиент согласовал цену», «платёж подтверждён», «товар передан перевозчику» — это понятнее, чем абстрактное «договор обработан».

Кто может его изменить? Иногда ответ — один человек, иногда — роль с двойным контролем. Важно не назвать должность, а описать правило: что именно можно исправить, до какого момента и какой след должен остаться.

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

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

Пример без сложных терминов

Представим, что менеджер оформляет заказ. В CRM он видит клиента и коммерческие условия. Учётная система проверяет наличие и резервирует товар. Финансовый контур подтверждает оплату. Личный кабинет показывает клиенту, что заказ принят.

Проблема начинается, когда все четыре части считают себя главным источником истины. Менеджер меняет количество в CRM. На складе уже есть резерв. Клиент видит старый срок. Бухгалтерия готовит счёт на прежнюю сумму. Каждая система по отдельности может работать исправно, но обязательство компании распалось на несколько версий.

Я бы не спешил объединять всё в одну большую базу. Сначала стоит решить, где именно фиксируется изменение, какие проверки проходят до него и какое сообщение получают остальные. У сообщения должны быть идентификатор, состояние и понятная реакция на повторную отправку. Это не избыточная техника: именно так интеграция остаётся управляемой, когда что-то пошло не по плану. Полезный разбор этого есть в статье о прослеживании одной операции через интеграцию.

Граница не равна запрету на изменения

Иногда границы понимают как жёсткую стену: «только эта система имеет право на данные, остальные молчат». В реальности системе нужны изменения. Вопрос в том, происходят ли они по понятному договору.

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

Что меняется при исправлении ошибки

Самая ценная проверка границы начинается не в идеальном сценарии, а когда факт надо исправить. Допустим, в заказе неверно указали количество. Можно ли просто переписать число? Иногда да — пока заказ не подтверждён. А после резерва, счёта или отгрузки такое изменение уже должно стать отдельным действием с причиной и следом.

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

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

Как не превратить границы в тяжёлую бюрократию

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

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

Для руководителя это ещё и способ говорить с командой без лишнего технического языка. Вместо вопроса «зачем нам отдельный сервис?» можно спросить: «Как мы не дадим разным частям компании одновременно пообещать клиенту разные вещи?». Ответ обычно быстро показывает, нужна ли новая граница или достаточно настроить существующий процесс.

Когда не нужно выделять новую часть системы

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

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

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

Короткий разговор перед стартом

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

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

Как проверить решение до разработки

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

Затем стоит спросить:

1. В какой системе видно текущее состояние обязательства?
2. Кто имеет право изменить его и почему?
3. Как другие системы узнают об изменении?
4. Что произойдёт, если сообщение придёт дважды или не придёт совсем?
5. Можно ли понять историю решения через неделю без устных пояснений?

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

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