Я сначала фиксирую правило, а потом выбираю технологию для архитектуры

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

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

Правило проще технологии

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

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

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

1. У каждого важного решения есть владелец. Не «отдел», не «система», а роль, которая может подтвердить изменение. Владелец не обязан делать работу руками, но он должен быть понятен тем, кто сталкивается с исключением.

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

3. У сбоя есть безопасное поведение. Если внешний сервис не ответил, система не должна просто исчезнуть в ошибке. Возможно, пользователь сможет сохранить черновик, сотрудник увидит задачу в очереди, а действие повторится позже. Главное — заранее решить, что нельзя потерять.

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

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

Проверка через один живой сценарий

Я люблю проверять архитектуру не общей схемой, а одной историей. Например: клиент оформил заказ, менеджер уточнил его, склад подтвердил резерв, оплата прошла с задержкой, а внешний сервис уведомлений оказался недоступен. Что увидит клиент? Где появится задача? Как сотрудник поймёт, что заказ не потерян? Кто решит, можно ли продолжать?

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

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

Архитектура не должна мешать изменению

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

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

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

Мой минимум перед архитектурным решением

• какое бизнес-правило защищает это решение;
• кто владеет правилом и данными;
• какой один пользовательский сценарий оно улучшает;
• что произойдёт при временном сбое;
• как отключить, заменить или откатить компонент;
• какой сигнал покажет, что всё идёт не так.

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