Решение как объект системы

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

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

Это требует онтологического сдвига.

Документ и решение — не одно и то же

Документ о выборе и решение — не одно и то же, даже если внешне они выглядят похоже.

ADR фиксирует факт выбора. Он описывает, что в определённый момент был принят конкретный вариант. Этого достаточно для документирования архитектурной истории. Этого недостаточно для управления системой во времени.

Решение — не запись о прошлом. Решение — активный элемент настоящего. Оно определяет, какое состояние системы считается допустимым сейчас, а какое — нет. Пока это различие не проведено, дальнейшая формализация невозможна.

На уровне структуры решение действительно может напоминать ADR. В нём есть формулировка, контекст, последствия. Это сходство не отрицается. Оно принципиально не является аргументом в пользу тождественности сущностей. Совпадение полей не означает совпадение роли.

Сущность определяется не формой хранения, а функцией в системе.

ADR отвечает на вопрос: «что мы тогда выбрали». Решение отвечает на другой: «что сейчас действует».

Эта разница не стилистическая. Она операциональная.

Решение как элемент управления состоянием

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

Поэтому формализация начинается не с формата и не с реализации. Она начинается с минимальных условий существования решения как объекта.

Минимальные условия существования решения

Эти свойства не являются схемой данных. Они не описывают, как хранить решение. Они описывают, при каких условиях можно утверждать, что решение существует как объект системы, а не как текст или воспоминание.

Идентичность

Решение должно быть однозначно различимо.

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

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

Решение не просто принимается. Оно переводит систему из одного состояния в другое.

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

Контекст применимости

Решение действует не всегда и не везде. Оно валидно при определённых условиях.

Контекст не поясняет формулировку и не оправдывает выбор. Он определяет границы действия решения. Вне контекста решение не интерпретируется и не может быть применено корректно.

Статус

Решение не бывает «просто записанным».

Оно либо действует, либо прекращено, либо вытеснено другим решением. Статус — это не метка документа. Это отражение текущего положения решения в системе. Без статуса невозможно определить, влияет ли решение на систему сейчас.

Формальная отменяемость

Решение должно уметь перестать существовать как действующее.

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

Возможность конфликта

Решение не изолировано.

Оно может вступать в противоречие с другими решениями. Эта возможность не дефект и не исключение. Это нормальное свойство системы, развивающейся во времени. Решение, которое не может конфликтовать, не встроено в реальность системы.

Указание вытесняющего решения

Если решение перестаёт действовать, должно быть возможно указать, чем именно оно было вытеснено.

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

Независимость от памяти людей

Решение существует в системе, а не в голове участника.

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

Граница применимости ADR

ADR принципиально не способен ответить на часть этих вопросов.

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

Даже идеально написанный ADR остаётся документом о прошлом. Он может быть полезен. Он может быть аккуратным. Он может быть структурированным. Но он не является объектом, управляющим допустимыми состояниями системы.

Это не критика ADR. Это фиксация границы его применимости.

Точка начала формализации

С этого момента различие становится недвусмысленным.

Если сущность не существует во времени как объект, если она не имеет статуса, если она не может быть отменена, если она не может конфликтовать, если она не может быть вытеснена другим решением, она остаётся документом.

Даже если выглядит осмысленно. Даже если аккуратно оформлена. Даже если похожа на решение.

Формализация начинается здесь.