Перейти к содержанию

D-02 · Границы сервисов в работающей системе#

Требуется история. Документ измеряет связность изменений по репозиторию и трекеру. Если системы ещё нет, измерять нечего, и это не «часть вопросов останется пустой» — это другой вопрос: не «где резать», а «какие границы заложить». Такое решение живёт в D-05.

Чем это решение отличается от выбора продукта. Варианты не берутся с рынка — их надо построить. Поэтому раздел 1 делает две вещи: собирает факты и порождает кандидатов. Рыночного слоя здесь нет; его место занимают типовые формы разреза — они не устаревают, и даты съёмки у раздела 4 нет.

Решение двустороннее. Силы разделения (разделы 2–4) взвешиваются против сил интеграции — того, что тянет части обратно друг к другу (Ford, Richards, гл. 7). Одна половина без другой даёт разрез, который выглядит обоснованным и не работает.

1. Что выяснить#

Сначала — что именно решаем#

Модульность и гранулярность — разные вопросы, и документ отвечает на оба. Их легко перепутать, потому что оба про «где сервисы»:

Вопрос Пример ответа
Модульность Где проходит линия между уже существующими частями Перенести профили из web в шлюз, граф подписок — к ленте
Гранулярность Насколько мелко резать: сколько частей и надо ли резать вообще Оставить модульный монолит; выделить третий сервис

Ответ «резать не надо» относится к гранулярности; ответ «резать здесь, а не там» — к модульности. На прогоне E-01 решалась гранулярность, на E-02 — модульность, и документ обслужил оба случая, не называя разницы. Назвать её нужно ради одного: дисквалификаторы и формы разреза у них разные. «Нет наблюдаемости» и «сервисов больше, чем команд» отсекают гранулярность — саму идею дробить. «Разрез по техническим слоям» и «больше одного пишущего» отсекают конкретную линию, то есть модульность.

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

Факты — из истории, а не из головы#

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

Вопрос Где смотреть Заполняет ось
Какая декомпозиция есть сейчас: какие части, что внутри каждой, кто владеет? Репозиторий, схема развёртывания, зоны ответственности Нулевой вариант — «оставить как есть»
Сколько изменений за последние 3–6 месяцев затронуло больше одного модуля? История коммитов и задач Связность изменений
Какие операции обязаны выполняться атомарно и какие инварианты нельзя нарушать? Требования из W0 Транзакционные разрывы
У каких таблиц и сущностей сегодня больше одного пишущего? Схема данных и код Владение данными
Где одно и то же слово означает разное? Глоссарий, разногласия на встречах Языковая чистота
Сколько команд, кто за что отвечает, как они договариваются? Состав команд и зоны ответственности Организационное соответствие
У каких частей профиль нагрузки или требования к доступности различаются на порядок? Замеры и SLO Технические причины разделения
Что по плану будет переписываться в ближайший год? Роадмап Стоимость перехода, обратимость
Есть ли данные, требующие особого режима защиты, и как они лежат относительно рассматриваемых линий? Требования W0, закон, договор, внутренняя политика Дисквалификатор и форма разреза

Текущий разрез — такой же кандидат, как остальные, и проходит дисквалификаторы наравне с ними. Он существует, значит выглядит нормальным; но чаще всего он сложился исторически, а не по решению, и первым же дисквалификатором оказывается «разрез по техническим слоям». На прогоне E-02 именно так и вышло: существующая граница web / posts шла по слоям, и 32 % сквозных задач были её симптомом. Без этого вопроса нулевой вариант не формулируется, а без нулевого варианта матрица сравнивает кандидатов не с реальностью, а друг с другом.

Четыре вопроса о силах интеграции#

Вопросы выше собирают доводы за разделение. Эти четыре собирают доводы против — то, что тянет части обратно друг к другу. Они заполняют не оси, а встречный список раздела 2.

Вопрос Где смотреть Какая сила
Какой код используют обе стороны линии и что с ним станет — дублирование, библиотека, свой сервис? Общие модули, зависимости Общий код
Какие внешние ключи, триггеры и представления пересекают линию? Схема данных Отношения в данных
Сколько процессов после разреза обязаны разговаривать через линию и с какой частотой? Основные сценарии, замеры Рабочий процесс
Нужна ли ACID-транзакция поперёк линии? Инварианты из W0 Транзакции

Последняя сила у нас уже работает дисквалификатором — «разрез разрывает атомарную операцию в основном сценарии». Здесь она названа для полноты: сила, доведённая до предела, перестаёт быть доводом и становится запретом. Остальные три предела не имеют и взвешиваются.

Вопросов стало одиннадцать при верхней границе в семь, и это сигнал. Возможно, документ пора делить по линии модульность / гранулярность. Пока не делим: разделяющий признак виден на двух случаях, и оба наши — ровно то основание, которого мы сочли недостаточным в прошлый раз. Записано в 96-backlog.md.

Вопросы, порождающие кандидатов#

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

  • Если резать по языку (ответ на четвёртый вопрос) — сколько получится частей и какие?
  • Если резать по тому, что меняется вместе (первый вопрос) — какие?
  • Если резать по командам (пятый) — какие?

Обычно получается два-три кандидата, и они частично совпадают. Совпадение — не совпадение: линия, на которой сошлись разные принципы, почти наверняка настоящая граница. Разошедшиеся линии и есть предмет решения.

2. Оси и дисквалификаторы#

Оси сравнения. Связность изменений · транзакционные разрывы · владение данными · языковая чистота · организационное соответствие · глубина синхронной цепочки · стоимость перехода · обратимость. Что писать в каждую — в таблице раздела 3.

Дисквалификаторы — проверяются до сравнения:

  • разрез разрывает операцию, обязанную быть атомарной, в основном сценарии — сага в главном пути, а не в исключении (DIST-08);
  • после разреза у сущности больше одного пишущего или остаётся общая таблица — это не граница, а её видимость;
  • разрез идёт по техническим слоям («сервис API», «сервис базы») — даёт связность на каждое изменение;
  • у получившегося сервиса нет владельца — некому дежурить, решать и отвечать за контракт;
  • нет наблюдаемости, автоматического выката и трассировки — для микросервисов это входное требование, а не следствие (OPS-07);
  • сервисов получается больше, чем команд, способных их содержать, и это не осознанное решение;
  • разрез рассекает класс защищаемых данных, и они оказываются у нескольких владельцев: каждый попадает в периметр аудита и обязан держать режим целиком — шифрование, аудит доступа, локализацию, ограниченный круг лиц. Стоимость режима умножается на число мест, и почти никогда это не окупается. Линию двигают, а не оплачивают (DATA-19, D-07);
  • части с разными целями по доступности или по темпу выката остаются в одном архитектурном кванте — общая база, общий выкат, синхронная связь на каждой операции. Квант имеет одну доступность, какие бы числа ни стояли в требованиях: 99,95 % на одной части и 99,9 % на другой внутри общего кванта — это 99,9 % на обеих. Либо квант делится вместе с сервисами, либо цели выравниваются по худшей, и это записывается как решение, а не остаётся расхождением между документами (Ford, Richards, гл. 7).

Первые три отсекают разрез, последние три отсекают саму идею разрезать сейчас — и это нормальный исход. Дисквалификатор о кванте отсекает не разрез и не идею, а требование: недостижимая цель по доступности снимается или оплачивается делением кванта.

Силы интеграции — встречная половина#

Ответы на четыре вопроса раздела 1 сводятся сюда. Сила интеграции — не балл и не ось: это счёт, который разрез выставляет. У каждой силы ровно два исхода, и третьего нет.

Сила Чем измеряется Оплатить можно так Когда отменяет линию
Общий код Сколько модулей используют обе стороны и как часто они меняются Дублировать (и принять расхождение) · вынести в библиотеку (и принять версионирование) · вынести в сервис (и принять ещё одну границу) Общий код — сама предметная логика: дублирование даст два расходящихся правила, библиотека — синхронный выкат обеих сторон
Отношения в данных Внешние ключи, триггеры и представления, пересекающие линию Денормализация (и сверка) · синхронизация событием (и отставание) · оставить данные с одной стороны Целостность обеспечивается связью на уровне БД и требуется инвариантом: после разреза её не обеспечивает никто
Рабочий процесс Сколько процессов пересекают линию и с какой частотой Уменьшить частоту (кэш, материализация, батч) · изменить процесс так, чтобы он не пересекал линию Пересечение происходит на каждой операции основного сценария и снять частоту нечем
Транзакции Нужна ли ACID поперёк линии — Всегда: это дисквалификатор выше, а не сила

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

Зачем встречный список, если есть оси и дисквалификаторы. Оси сравнивают кандидатов между собой, дисквалификаторы запрещают. Ни то, ни другое не удерживает довод «эти части лучше не разделять вовсе» — он проваливается между ними, и разрез получается обоснованным по всем осям и всё равно плохим. Прогон E-02 прошёл без этого списка, и общий код в нём не обсуждался ни разу — не потому, что его не было, а потому, что спросить было нечем.

3. Матрица оценки#

Колонки — кандидаты, построенные в разделе 1. В ячейках факты с пометкой источника, не баллы.

Словарь пометок здесь свой. Вендорской документации в этом решении нет, поэтому [док] не встречается: [история N мес] — из репозитория или трекера за указанный период, [схема] — из схемы данных и кода, [требования] — из инвариантов W0, [орг] — из состава команд, зон ответственности и принятой терминологии, [нет данных]. Правило общее для всех решений: ячейка без пометки считается непроверенной.

Пример условный. Числа выдуманы, форма — настоящая.

Ось Что записывать в ячейку Модульный монолит (сейчас) Разрез A — по языку Разрез B — по командам
Связность изменений Доля задач за период, уместившихся в одну границу — процентом, не ощущением 100 % по определению — границы внутри процесса 82 % из 140 задач [история 6 мес] 61 % — каталог и биллинг меняются вместе [история 6 мес]
Транзакционные разрывы Список операций основного сценария, пересекающих границу, и какая согласованность обязательна в каждой — не количество Нет Одна: списание остатка при оформлении, требуется атомарность [требования] Три, включая оплату; двум достаточно итоговой [требования]
Владение данными Сколько сущностей после разреза имеют больше одного пишущего 0 — один процесс 0 [схема] 2 — заказ пишут каталог и биллинг [схема]
Языковая чистота Сколько терминов остаётся с двойным значением внутри одной границы 4 — «заказ» значит разное в трёх модулях [орг] 0 — разрез строился по языку [орг] 3 [орг]
Организационное соответствие Сколько команд владеет больше чем одной границей и наоборот Неприменимо — одна кодовая база Одна команда владеет двумя контекстами [орг] Полное — разрез строился по командам [орг]
Глубина синхронной цепочки Сколько сетевых вызовов в основном пользовательском сценарии 0 2 [схема] 4 — оформление проходит через все [схема]
Стоимость перехода Сколько шагов миграции от сегодняшнего состояния и что ломается в каждом 0 — уже здесь 3 шага strangler fig, разделение таблицы заказов [схема] 2 шага, но общая база на переходный период [схема]
Обратимость Что стоит переделать, если граница окажется ложной Перенос модуля — дни Перенос между сервисами — недели плюс миграция данных То же

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

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

Порог — около 80 % задач в одной границе. Ниже — линия проведена не там: каждая третья задача тянет согласование двух команд, двух выкатов и двух контрактов. Выше 90 % — обычно признак того, что границ мало или период измерения слишком короткий. Это ориентир для разговора, а не критерий приёмки: он зависит от длины периода, от того, что считать задачей, и от доли инфраструктурной работы. Называть его всё равно нужно — без него доля «68 %» не интерпретируется, и на прогоне E-02 порог пришлось брать из условий пересмотра чужого ADR, то есть из примера, а не из метода.

Разрыв считается ценой, а не количеством. Разрез определяет, какие рабочие процессы станут распределёнными, — но не то, как они будут выполняться. Это выбирается потом и отдельно для каждого процесса, по трём независимым осям (Ford, Richards, «Software Architecture: The Hard Parts», гл. 12):

Ось Значения
Взаимодействие синхронное · асинхронное
Согласованность атомарная · итоговая
Координация оркестровка · хореография

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

Почему эти три оси не стали осями матрицы. Они описывают динамическую связанность — как сервисы общаются во время работы. Разрез — это статическая связанность: кто от кого зависит и кто чем владеет. Сравнивать кандидатов по «синхронно или асинхронно» нельзя: это не свойство разреза, а решение, принимаемое после него. Связь односторонняя — разрез задаёт, для каких процессов этот выбор вообще придётся делать, и в этом качестве три силы уточняют одну ось, а не добавляют три. Сам выбор — отдельное решение: D-04 · Связь сервисов в рабочем процессе, по одному применению на процесс.

4. Типовые формы разреза#

Рынка здесь нет: границу не покупают. Место рыночного слоя занимают формы разреза — способы провести линию, каждый со своим условием применимости. Они не устаревают, поэтому даты съёмки у раздела нет; вместо неё — источники.

Форма По какому признаку режет Когда даёт верную границу Чем оборачивается при ошибке Статус у нас
По поддомену — пространство задачи По тому, чем занимается бизнес: области деятельности, которые существовали бы и без нашей системы Области деятельности различимы и устойчивы Разрез по вывеске: поддомены названы, а модель внутри осталась общей заполняется в проекте
По ограниченному контексту — пространство решения По языку: где термин меняет значение. Граница контекста проходит там, где ломается единый язык (Эванс) Предметная область развитая, язык устоявшийся Контексты, не совпадающие с реальной работой
По бизнес-способности По тому, что организация умеет делать Способности стабильнее, чем структура команд Разрез повторяет оргсхему прошлого года
По транзакционной границе По тому, что обязано меняться атомарно Есть жёсткие инварианты: деньги, остатки, лимиты Границ мало, сервисы крупные — но это редко проблема
По скорости изменений По тому, что меняется часто и что почти никогда Часть системы переписывается регулярно Граница устаревает вместе с роадмапом
По владению данными Один пишущий на сущность Данные уже структурированы, владельцы очевидны Россыпь мелких сервисов вокруг таблиц
По команде — закон Конвея, применённый сознательно По зонам ответственности людей Команды стабильны и автономны Перестройка команд ломает архитектуру
По профилю нагрузки или требованиям По тому, что надо масштабировать или изолировать отдельно Разница измерена, составляет порядок и у выделяемой части есть свои данные Вместо границы получается кэш, названный сервисом
По классу защищаемых данных По тому, что требует особого режима: персональные данные, платёжные, врачебная тайна Класс очерчен и его можно сузить до одной границы Режим приходится держать везде, куда класс просочился
По техническим слоям — анти-форма По слоям: API, логика, доступ к данным Никогда для границ между сервисами Связность на каждое изменение: любая задача трогает все

Поддомен и ограниченный контекст — не одно и то же, и раньше в этой таблице они стояли одной строкой. Поддомен лежит в пространстве задачи: это то, чем занимается бизнес, и оно существовало бы, даже если бы нашей системы не было. Ограниченный контекст лежит в пространстве решения: это модель, которую проводим мы, и граница, за которой её термины перестают действовать. Совпадение одного с другим — цель, а не данность: устаревшая модель спокойно обслуживает два поддомена одним контекстом, и на прогоне E-02 было именно так — сервис web держал ленту, профили и подписки, то есть три области деятельности в одной модели. Разрез «по поддомену» в такой ситуации назовёт правильные части и не тронет модель; разрез «по контексту» тронет модель и может разойтись с тем, как устроен бизнес. Проверять стоит обоими.

Критерий «по языку» — это метод, а не наблюдение. Единый язык (Эванс) — свойство внутренности контекста: внутри одно слово значит одно, и как только для одних и тех же данных нужны два разных значения, граница уже проходит здесь, просто её ещё не провели. Без этого имени критерий читается как бытовая эвристика «слова разные — режем тут», и тогда по нему режут синонимы вместо контекстов.

Колонка «статус у нас» заполняется теми же тремя значениями, что и рыночный слой: используем · не используем, потому что… · не рассматривали. Здесь она фиксирует принятый в команде принцип разреза, и второе значение так же ценно: «по командам не режем, потому что состав меняется каждые полгода» — это решение, к которому иначе возвращаются на каждом обсуждении.

Осторожно с разрезом по профилю нагрузки. Разница в нагрузке — самый обманчивый признак: она заметна, измерима и почти никогда не является границей. Проверка в одну строку: есть ли у выделяемой части собственный язык, собственные инварианты и собственный владелец данных? Если нет — это проекция чужих данных для ускорения чтения, и решается она кэшем или репликой (D-03), а не границей сервиса. На прогоне E-01 двадцатисемикратная разница чтений и записей выглядела основанием для разреза ровно до этой проверки.

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

5. Эвристики#

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

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

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

Если модулей ещё нет — порядок другой, и час превращается в дни. В системе без выделенных границ доля «уместившихся в одну границу» не определена ни для чего, кроме тривиальных 100 % у нулевого варианта. Тогда:

Что Как
Когда считать После построения кандидатов, по каждому отдельно — а не первой. Правило «связность считается первой» относится к системе, где границы уже есть
По чему считать По коммитам, если задачи ведутся нерегулярно. На прогоне E-03 было 268 коммитов против 94 задач за те же полгода
Сколько стоит Дни, а не час: сопоставление файлов с кандидатами — отдельная работа, и на 340 таблицах с неизвестными владельцами она заняла три дня

И различать две нехватки истории. Нет истории происхождения (почему таблица появилась, кто её завёл) — это не нехватка для D-02; нет истории изменений за период — это она и есть. Первое бывает при живом репозитории, и решение не блокирует.

Давление «микросервисы, потому что так делают». Проверить по ARCH-01, какая из причин применима: разный цикл релизов, разные команды-владельцы, разный профиль нагрузки или надёжности, организационный масштаб. Если ни одна — причина не техническая, и обсуждать надо её, а не архитектуру.

Отложить — здесь это конкретная конструкция, а не бездействие. Модульный монолит с явными границами модулей, запретом на чужие таблицы и проверкой зависимостей на сборке даёт ту же дисциплину при цене ошибки в днях (ARCH-01). Условие возврата записывается не сроком, а событием: появилась вторая команда-владелец, профиль нагрузки частей разошёлся на порядок, понадобился независимый выкат.

6. Запись в ADR#

Поле ADR Чем заполняется отсюда
Контекст Ответы на семь вопросов раздела 1 — числами, с периодом, за который они посчитаны
Дисквалификаторы Какие кандидаты отпали без сравнения и по какому условию
Рассмотренные варианты Кандидаты вместе с принципом, по которому построен каждый — заполненная матрица целиком, снимком
Решение Выбранный разрез: перечень границ и владелец каждой сущности
Обоснование Какие оси перевесили; если была ничья — какая эвристика применена
Последствия Какие операции становятся сагами, какие вызовы — сетевыми, что дорожает в эксплуатации
Условия пересмотра Раздел 7
Самая дорогая будущая граница По какой линии разрез обойдётся дороже всего и почему — обычно по ней идёт транзакция основного сценария. Через год это первое, что нужно знать, и последнее, что кто-либо помнит
Метод D-02 v<версия> · шаблон ADR v<версия> — две позиции вместо трёх: раздел 4 не датирован

Перечень границ с владельцами — главный выход этого решения: он переживает сам разрез и используется дальше на W3 и W6. Матрица копируется в ADR снимком, а не прикладывается ссылкой: ADR отвечает на вопрос, почему так решили тогда, а связность изменений через год будет другой.

7. Условия пересмотра#

  • Изменился состав или число команд. Закон Конвея работает и в обратную сторону: архитектура, не совпадающая с коммуникациями, воспроизводит их через обходные пути.
  • Доля изменений внутри одной границы упала ниже зафиксированного в матрице значения — граница перестала быть границей.
  • В основном сценарии появилась сага, которой при выборе не было.
  • У сущности появился второй пишущий.
  • Профиль нагрузки или требования к доступности частей разошлись на порядок — появилась техническая причина, которой не было.
  • Отложенное решение вернулось по своему условию: модульный монолит перестал устраивать по одному из записанных событий.

Проверка перед тем, как считать решение принятым — пять пунктов в шаблоне.

История версий#

Версия Дата Изменение
5.1 2026-09-18 MINOR, по итогам прогона E-03. Уточнена эвристика о связности для системы без выделенных модулей: считается по кандидатам после их построения, по коммитам при нерегулярных задачах, и стоит дни, а не час. Различены две нехватки истории — происхождения и изменений. Прежний исход правило не меняет
5.0 2026-09-17 MAJOR. Добавлен класс защищаемых данных как участник решения о границах: вопрос в раздел 1, дисквалификатор «разрез рассекает класс защищаемых данных» и одноимённая форма разреза. Повод — разбор пилота И0′: требования к данным особого режима влияют не только на хранение, но и на то, где проходит линия. Старым ADR: проверить, не оказались ли персональные, платёжные или иные защищаемые данные у нескольких владельцев — если да, режим оплачивается столько раз, сколько мест
4.0 2026-09-17 MAJOR, по итогам прогона E-02 и разбора глав 6–7 Форда и Ричардса. Решение стало двусторонним: добавлены четыре вопроса и встречный список сил интеграции (общий код, отношения в данных, рабочий процесс, транзакции) с правилом «оплачена названной ценой или отменяет линию». Добавлен вопрос о существующей декомпозиции и правило, что текущий разрез проходит дисквалификаторы наравне с кандидатами. Добавлен дисквалификатор об архитектурном кванте: разные цели по доступности внутри одного кванта недостижимы. Назван порог связности изменений (~80 %) как ориентир. Введено различение модульности и гранулярности. Форма разреза «по поддомену и ограниченному контексту» разделена на две, критерий «по языку» связан с единым языком Эванса. Старым ADR: проверить, обсуждался ли общий код и не остались ли части с разными целями по доступности в одном кванте — оба вопроса прежняя версия задать не могла
3.0 2026-09-16 MAJOR, по итогам прогона E-01. Область применения сужена до работающей системы: документ измеряет связность изменений, и на гринфилде его раздел 1 неприменим — эта половина выделена в D-05. Добавлена проверка разреза по профилю нагрузки (свой язык, свои инварианты, свой владелец данных — иначе это кэш, а не граница) и поле «самая дорогая будущая граница». Старым ADR: если решение принималось на системе без истории изменений, метод был неприменим — перепройти по D-05. Предписание относится к E-01 · ADR-0002 и по состоянию на 2026-09-21 не исполнено. Развилкой Ж6 решено не исполнять его задним числом: D-05 выведен из этого же прогона, и проверять им этот прогон — замкнутый круг. Первое применение D-05 идёт на свежем гринфилде, шаг Ш2 плана.
2.1 2026-09-16 MINOR: ссылка вперёд на D-04, где выбирается ячейка для каждого разорванного процесса. Метод не изменился
2.0 2026-09-16 MAJOR: ось «транзакционные разрывы» заполняется ценой, а не количеством — для каждого разрыва указывается требуемая согласованность. Старым ADR: пересчитать сравнение, если у кандидатов разное число разрывов — ранжирование могло измениться. Добавлено разграничение статической и динамической связанности
1.0 2026-09-16 Первая версия: 7 вопросов к истории изменений плюс вопросы, порождающие кандидатов; 8 осей, 6 дисквалификаторов, 8 типовых форм разреза, 5 эвристик