Boundary: границы между областями

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

Scope уже ввёл координату: где работает механика DR/CCR/CR/RD. Дальше появляется практическая поломка: области не изолированы. Они обмениваются данными, вызывают друг друга, делят ответственность за один результат.

Пока стык не выражен как объект, система не может ответить на вопрос:
кто и на каких правилах отвечает за корректность перехода между областями.

Boundary — это не документ и не обсуждение

Boundary нужен как решение, а не как описание.

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

Критерий различия простой:
документ можно отредактировать без изменения реальности; boundary изменяет реальность действия — потому что он обязует.

Если подменить boundary документом, ломается следующее:

• граница начинает “существовать” только там, где её описали;
• исправление формулировки начинает выглядеть как изменение стыка;
• исчезает момент, с которого переход между областями стал считаться корректным;
• невозможно доказать, что стык был заменён, а не “просто переписан”.

Обсуждение — процесс согласования.
Boundary — результат: действующее правило, по которому области соприкасаются.

Критерий различия:
обсуждение отвечает на вопрос «как договоримся», boundary отвечает на вопрос «как обязано работать».

Если подменить boundary обсуждением, ломается следующее:

• правила стыка становятся недоказуемыми: “где-то договаривались”;
• новые участники вынуждены угадывать, что считается корректным переходом;
• CR невозможно сформулировать точно: непонятно, какой именно стык нарушен;
• RD превращается в повторный спор, а не в управляемое восстановление определённости.

Boundary как решение о границе ответственности

Boundary — это решение о границе ответственности между scope.

Он отвечает на два вопроса, которые нельзя свести к “интеграции”:

• где заканчивается обязательность решений одного scope;
• по каким правилам второй scope принимает то, что приходит снаружи.

Boundary не является отдельным классом сущностей.
Это DR с особым предметом: он описывает не поведение внутри области, а правила взаимодействия областей.

Точно так же, как RD — это DR с особой ролью, boundary — это DR с особой семантикой.

Граница действует во времени

Граница не является “схемой системы”.
Она действует, вытесняется и прекращает действие так же, как любое решение.

Минимальные условия существования boundary как действующего объекта:

1. Есть две области применимости
   Boundary невозможен без минимум двух scope, которые соприкасаются. Scope — это не “пространство записей”, а место действия механики.

2. Есть правило ответственности и взаимодействия
   Boundary фиксирует, что считается корректным взаимодействием между этими областями. Не “как реализовать”, а “что обязует”.

3. Есть момент, с которого правило обязует
   Граница должна иметь момент вступления в силу. Без этого невозможно различить “раньше было так” и “теперь так”.

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

Boundary Record: минимальная структура и зачем она системе

Если boundary фиксируется как запись, это не “описание интеграции”.
Это фиксация действующего выбора о стыке.

Минимально boundary record должен выражать следующее:

Указание соприкасающихся scope

Нужно, чтобы было ясно, какие области связаны этим boundary.
Без этого boundary превращается в абстрактную норму “между всем и всем”.

Формулировка правила стыка

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

Разделение ответственности

Нужно, чтобы было однозначно: какая часть корректности обеспечивается одним scope, а какая — другим.
Это ядро boundary: он разделяет ответственность, а не просто связывает.

Момент вступления в силу

Нужен для причинности: с какого момента переход между областями должен оцениваться по этому правилу.

Другие элементы (метрики, теги, уровни логирования) не усиливают сущность boundary. Они относятся к внедрению.

Почему границы конфликтуют чаще всего

Внутри одного scope конфликт обычно сводится к несовместимости правил поведения: DR <> DR или DR <> CCR.
На стыке конфликт возникает по другой причине: две области пытаются одновременно считать себя “источником истины” об одном и том же переходе.

Это делает границы структурно конфликтными.

Типовые формы конфликтов:

• Boundary <> DR (внутри scope): внутреннее решение требует поведения, которое boundary запрещает или ограничивает при выходе наружу.
• Boundary <> CCR: изменение внешних условий делает прежние правила стыка некорректными, хотя оба scope внутри себя остаются последовательными.
• Boundary <> Boundary: два действующих решения по одному и тому же стыку задают несовместимые правила взаимодействия.

В этих ситуациях CR фиксирует несовместимость как факт, а RD возвращает определённость, изменяя картину действующих решений относительно конкретного конфликта.

Ключевой вывод: граница конфликтует не потому, что она “сложная”.
Она конфликтует потому, что на стыке пересекаются разные области истинности и обязующести.

Следствия корректной модели

Если boundary не является объектом, становится невозможным:

• отличить “граница изменилась” от “кто-то иначе понял”;
• зафиксировать CR так, чтобы он был проверяемым фактом, а не описанием инцидента;
• применить RD адресно: непонятно, какой стык стал определённым;
• удерживать историю ответственности: почему в какой-то момент “это было на стороне A”, а потом стало “на стороне B”.

Если boundary существует как решение о границе, становится прозрачным:

• где именно проходит разделение ответственности между scope;
• по каким правилам взаимодействие считается корректным;
• какие решения создают несовместимость на стыке;
• с какого момента стык должен интерпретироваться иначе.