В сценарии два модуля не вызывают друг друга напрямую, но корректная работа требует строго заданного порядка их операций. Какой скрытый вид связанности возник?
Возникла временная связанность: корректность одного модуля зависит не только от данных или интерфейса другого, но и от того, когда и в каком порядке выполняются операции. Такая зависимость означает, что архитектурная граница скрывает протокол взаимодействия.
По мере разделения программ на модули команды стремились уменьшить прямые вызовы и зависимости между компонентами. Однако удаление ссылки на другой модуль само по себе не устраняет связанность: она может сохраниться в виде неявных требований к порядку действий.
Понятие временной связанности помогает обнаружить такие скрытые протоколы. Изначально это особенно важно для систем, где операции выполняются поэтапно: сначала подготавливаются данные, затем фиксируется состояние, после чего запускается следующий процесс.
Например, один модуль публикует данные, а другой должен сначала дождаться их обработки и только затем выполнять следующую операцию. Формально они могут взаимодействовать через очередь или общее хранилище, но нарушение порядка приведёт к ошибке, неполному состоянию или повторной обработке.
Такая связанность ухудшает независимую эволюцию модулей. Изменение задержек, повторная доставка сообщения, параллельный запуск или частичный сбой могут нарушить предположение о последовательности, которое нигде явно не описано.
Нужно сделать протокол явным. Обычно это означает, что компонент-координатор управляет этапами процесса, а модули сообщают о своих состояниях через определённые контракты. Если порядок действительно является частью бизнес-правила, его следует выразить состояниями или переходами, а не оставлять неформальным соглашением между разработчиками.
Важно различать временную связанность и обычную последовательность вызовов внутри одной операции. Последовательность локальных шагов может быть внутренней деталью модуля; временная связанность становится архитектурной проблемой, когда другой модуль должен знать или угадывать эту последовательность.
Для устойчивости применяют идемпотентность, явные статусы, проверку допустимости переходов, повторяемые сообщения и корреляционные идентификаторы. Если взаимодействие асинхронное, потребитель не должен полагаться только на физический порядок доставки: сообщения могут прийти повторно, с задержкой или в другом порядке.
Возможен компромисс: явный координатор добавляет инфраструктурную логику и состояние процесса, зато делает зависимость видимой и тестируемой. Полностью устранить временную связанность нельзя, если сам бизнес-процесс имеет обязательные этапы; задача архитектуры — локализовать её и превратить в проверяемый контракт.
В системе оформления возврата сначала нужно зарегистрировать решение о возврате, затем дождаться подтверждения склада и только после этого перечислить деньги клиенту. Команды разделили склад и платежи на независимые сервисы, поэтому прямой вызов между ними отсутствовал, но платёжный сервис фактически предполагал, что склад уже завершил проверку.
Рассматривались три варианта. Общая транзакция упростила бы согласованность, но связала бы сервисы доступностью и временем выполнения друг друга. Прямой синхронный вызов сделал бы порядок явным, но добавил бы цепочку отказов и жёсткую зависимость. Независимые события без фиксации состояния были дешевле, однако оставляли риск выплаты при устаревшем или неполном результате проверки.
Выбрали координатор процесса с явными состояниями «возврат зарегистрирован», «склад подтвердил» и «выплата разрешена». Платёжная операция стала идемпотентной, а повторные и запоздалые сообщения проверялись по идентификатору возврата и текущему состоянию. В результате порядок перестал быть скрытым соглашением, а сбои можно было безопасно повторять и диагностировать.
Нет. Некоторые бизнес-процессы по смыслу последовательны: нельзя перечислить деньги до подтверждения права на возврат. Проблема возникает не из-за самого порядка, а из-за его неявности, распределённости и отсутствия проверяемого контракта.
Хорошая архитектура не отменяет обязательные этапы, а помещает их в явную модель процесса. Тогда порядок можно тестировать, наблюдать и изменять независимо от внутренней реализации отдельных модулей.
Очередь убирает прямую синхронную зависимость, но не отменяет требования к состоянию процесса. Потребитель всё ещё может быть обязан обработать событие только после другого события или проверить, что предыдущий этап завершён.
Кроме того, доставка может быть повторной, задержанной или нарушить порядок. Поэтому нужны идентификаторы операций, проверка допустимых переходов и обработчики, безопасные при повторном выполнении.
Зависимость данных означает, что модулю нужны конкретные данные другого модуля или общий формат их представления. Временная связанность означает, что важен момент или порядок операции, даже если модули обмениваются только независимыми сообщениями.
Они могут существовать одновременно. Например, модулю платежей может требоваться идентификатор возврата, а также подтверждение складского этапа до начала выплаты. Для снижения связанности данные следует передавать через стабильный контракт, а порядок — выражать состояниями процесса, а не неявными договорённостями.