{
  "index": 57,
  "slug": "editorial-2026-06-practice-multi-runtime",
  "title": "PHP, JavaScript и D: как не потерять смысл на общей границе",
  "excerpt": "Три runtime могут передавать один payload и всё равно принимать разные решения. Разбираем узкий контракт результата, ошибки, времени и диагностики с воспроизводимой fail-closed проверкой.",
  "contentHtml": "<p>На границе одного сервиса с другим ответ выглядит одинаково: PHP сформировал заказ, JavaScript показал его в интерфейсе, а обработчик на D получил те же поля для следующего шага. Проблема появляется не в формате, а в решении. Один потребитель считает отсутствие <code>error</code> успехом, второй ждёт исключение, третий подставляет ноль вместо пропущенной суммы.</p>\n<p>Цена расхождения быстро становится практической. Интерфейс может показать готовый заказ, worker — повторить уже выполненную операцию, а расследование не свяжет запись D с исходным запросом PHP. Команда видит один JSON и спорит о языках, хотя сначала надо ответить на более узкий вопрос: какие значения, состояния и правила этот JSON обязан сохранять?</p>\n<p>В этой заметке я использую маленький boundary contract — договор на стыке компонентов. Он не описывает всю систему. Он фиксирует одну операцию, версию схемы, тип результата, режим завершения, шкалу времени, идентификатор связи и правило преобразования. Если поле нельзя сравнить буквально, проверка останавливается и возвращает причину.</p>\n<h2>JSON переносит форму, но не решение</h2>\n<p>JSON удобен именно своей малой грамматикой: объект, массив, строка, число, логическое значение и <code>null</code>. RFC 8259 описывает его как текстовый формат обмена структурированными данными. Но в этих типах нет ответа на вопросы «можно ли повторить операцию», «что означает пустое поле» и «кто владеет отказом».</p>\n<p>Даже поле <code>amount: 4200</code> не сообщает единицу. Это могут быть копейки, рубли, лимит или внутренний счётчик. Число также имеет границу переносимости: RFC 8259 отдельно отмечает точное согласование целых чисел в диапазоне от <code>-(2**53)+1</code> до <code>(2**53)-1</code> для реализаций с IEEE 754 binary64. Значит, «число в JSON» — ещё не денежный тип. Единицу и допустимый диапазон задаёт контракт приложения.</p>\n<p>Имена объекта должны быть уникальными: при дубликатах разные реализации могут оставить последнее значение, вернуть ошибку или сохранить несколько пар. Это ещё одна причина не строить протокол на случайном поведении парсера. На границе нужны уникальные поля и проверяемые правила, а не надежда на одинаковую реакцию библиотек.</p>\n<div class=\"table-scroll\"><table><caption>Что добавляет контракт поверх JSON</caption><thead><tr><th scope=\"col\">Слой</th><th scope=\"col\">Пример</th><th scope=\"col\">Вопрос для проверки</th></tr></thead><tbody><tr><td>Форма</td><td><code>result.tag</code> и набор полей</td><td>Ответ можно разобрать без догадок?</td></tr><tr><td>Единица</td><td><code>amountMinor</code> в RUB</td><td>Одинакова ли шкала значения?</td></tr><tr><td>Состояние</td><td><code>outcome.kind: accepted</code></td><td>Это успех, отказ или незавершённая операция?</td></tr><tr><td>Время</td><td><code>basis: logical-ticks</code></td><td>Можно ли сравнить начало и конец?</td></tr><tr><td>Связь</td><td><code>correlationId</code></td><td>По какому ключу искать одну операцию?</td></tr><tr><td>Преобразование</td><td><code>mapping: exact</code></td><td>Значение сохранено или незаметно изменено?</td></tr></tbody></table></div>\n<figure><img src=\"/assets/editorial/2026/multi-runtime-2026-contract-boundary-map.svg\" alt=\"PHP, JavaScript и D передают данные через общий контракт с полями результата, состояния, времени и идентификатора операции\" loading=\"lazy\" /><figcaption>Схема показывает состав boundary contract. Стрелки обозначают проверку формы записи, а не сетевое соединение и не запуск трёх runtime.</figcaption></figure>\n<h2>Сначала зафиксировать одну операцию</h2>\n<p>Широкий объект «данные заказа» плохо проверяется. В нём смешиваются бизнес-решение, транспортные детали, диагностические поля и состояние побочного эффекта. Для первой версии лучше выбрать одну операцию, например <code>fixed-order-decision</code>, и описать только результат этой операции.</p>\n<p>У каждого поля должен быть владелец смысла. Producer отвечает за то, что <code>order-ready</code> означает именно готовый результат, а не текст для интерфейса. Consumer не должен угадывать смысл по имени поля или по тому, что значение похоже на знакомый тип. Он принимает только известную версию и явно отказывается от незнакомой.</p>\n<p>Для демонстрации подойдёт фиксированная запись: сумма хранится в минимальных единицах, валюта названа отдельно, ошибка представлена envelope, а время задано логическими отметками. Такая запись воспроизводима: её результат не зависит от часов, сети, файлов и случайного порядка выполнения.</p>\n<h2>Три оси, которые нельзя смешивать</h2>\n<p><strong>Значение.</strong> Поле <code>result.tag</code> отделяет вид результата от его хранения. Для суммы нужны <code>amountMinor</code>, <code>currency</code> и правило диапазона. Не следует превращать пропущенную сумму в ноль: это два разных состояния, и у них должны быть разные tag или явное состояние отсутствия.</p>\n<p><strong>Завершение.</strong> Поле <code>outcome.kind</code> отвечает на вопрос, чем закончилась операция. В примере допустимы <code>accepted</code> и <code>rejected</code>, а <code>error</code> содержит стабильный <code>code</code> и правило <code>retry</code>. Текст сообщения можно показывать человеку, но нельзя делать его единственным ключом для автоматики.</p>\n<p>Механизмы языков здесь различаются. PHP Manual описывает <code>throw</code>, <code>catch</code> и подъём исключения по стеку до обработчика. Спецификация ECMAScript использует Completion Record с типами <code>normal</code> и <code>throw</code> для описания значения и передачи управления. Документация D также строит обработку вокруг исключений и размотки стека. Эти источники объясняют механизмы внутри языков, но не создают общего протокола. На границе исключение надо явно сопоставить с полями envelope либо вернуть отказ.</p>\n<p><strong>Время.</strong> <code>logical-ticks</code> в примере нужны только для проверки порядка: <code>closed: 108</code> больше <code>opened: 100</code>. Это не миллисекунды и не измерение задержки. Если продукту нужна длительность, контракт должен назвать источник часов, единицы, точку старта и точку окончания. Календарная дата, monotonic clock и порядковая отметка решают разные задачи.</p>\n<p><strong>Связь.</strong> <code>correlationId</code> связывает записи одной операции, но не доказывает, что запрос дошёл до следующего компонента. Уникальный идентификатор помогает искать события; доказательство доставки требует отдельного наблюдаемого результата. Не надо восстанавливать связь по совпавшему времени или одинаковой сумме.</p>\n<div class=\"table-scroll\"><table><caption>Минимальная семантическая матрица</caption><thead><tr><th scope=\"col\">Ось</th><th scope=\"col\">Явное поле</th><th scope=\"col\">Неверная подмена</th><th scope=\"col\">Остановка</th></tr></thead><tbody><tr><td>Результат</td><td><code>tag: order-ready</code></td><td>Выводить тип по наличию <code>amountMinor</code></td><td><code>stop-unknown-result-tag</code></td></tr><tr><td>Ошибка</td><td><code>kind</code>, <code>code</code>, <code>retry</code></td><td>Считать отсутствие исключения успехом</td><td><code>stop-mixed-outcome</code></td></tr><tr><td>Время</td><td><code>basis</code>, <code>opened</code>, <code>closed</code></td><td>Называть ticks миллисекундами</td><td><code>stop-unknown-time-basis</code></td></tr><tr><td>Связь</td><td><code>correlationId</code></td><td>Искать событие по timestamp</td><td><code>stop-missing-correlation</code></td></tr></tbody></table></div>\n<h2>Воспроизводимая проверка в памяти</h2>\n<p>Ниже обычный JavaScript без внешних зависимостей. Он проверяет заранее заданные literals, поэтому его можно сохранить в <code>boundary-check.mjs</code> и выполнить командой <code>node boundary-check.mjs</code>. Запись с меткой <code>php</code> не запускает PHP, а запись <code>d</code> не запускает D: это участники проверочной матрицы.</p>\n<pre><code>const contract = {\n  schemaVersion: 'boundary-1',\n  operation: 'fixed-order-decision',\n  result: { tag: 'order-ready', amountMinor: 4200, currency: 'RUB' },\n  outcome: { kind: 'accepted', error: null, retry: 'never' },\n  time: { basis: 'logical-ticks', opened: 100, closed: 108 },\n  correlationId: 'demo-order-42'\n};\n\nconst adapters = [\n  { runtime: 'php', version: 'boundary-1', resultTag: 'order-ready',\n    outcomeKind: 'accepted', timeBasis: 'logical-ticks', mapping: 'exact' },\n  { runtime: 'javascript', version: 'boundary-1', resultTag: 'order-ready',\n    outcomeKind: 'accepted', timeBasis: 'logical-ticks', mapping: 'exact' },\n  { runtime: 'd', version: 'boundary-1', resultTag: 'order-ready',\n    outcomeKind: 'accepted', timeBasis: 'logical-ticks', mapping: 'exact' }\n];\n\nconst expectedRuntimes = new Set(['php', 'javascript', 'd']);\n\nfunction review(input, peers) {\n  if (input?.schemaVersion !== 'boundary-1' ||\n      input.operation !== 'fixed-order-decision') {\n    return { status: 'stop-incomplete-contract' };\n  }\n  if (input.result?.tag !== 'order-ready' ||\n      !Number.isInteger(input.result.amountMinor) ||\n      !input.result.currency) {\n    return { status: 'stop-unknown-result-tag' };\n  }\n  if (input.outcome?.kind !== 'accepted' || input.outcome.error !== null ||\n      input.outcome.retry !== 'never') {\n    return { status: 'stop-mixed-outcome' };\n  }\n  if (input.time?.basis !== 'logical-ticks' ||\n      !Number.isInteger(input.time.opened) ||\n      !Number.isInteger(input.time.closed) ||\n      input.time.closed &lt; input.time.opened) {\n    return { status: 'stop-unknown-time-basis' };\n  }\n  const runtimes = new Set(peers.map((peer) =&gt; peer.runtime));\n  if (runtimes.size !== expectedRuntimes.size ||\n      [...expectedRuntimes].some((runtime) =&gt; !runtimes.has(runtime))) {\n    return { status: 'stop-missing-adapter' };\n  }\n  const invalid = peers.find((peer) =&gt;\n    peer.version !== input.schemaVersion ||\n    peer.resultTag !== input.result.tag ||\n    peer.outcomeKind !== input.outcome.kind ||\n    peer.timeBasis !== input.time.basis ||\n    peer.mapping !== 'exact'\n  );\n  if (invalid) {\n    return { status: 'stop-incomparable-adapter', runtime: invalid.runtime };\n  }\n  return {\n    status: 'contract-consistent',\n    elapsedTicks: input.time.closed - input.time.opened,\n    externalSystems: 'not observed'\n  };\n}\n\nconsole.log(review(contract, adapters));\nconst coerced = adapters.map((peer) =&gt;\n  peer.runtime === 'd' ? { ...peer, mapping: 'coerce' } : peer\n);\nconsole.log(review(contract, coerced));</code></pre>\n<p>Положительный вывод означает только три вещи: поля одной записи прошли названные проверки, три model label присутствуют, а интервал упорядочен. Вторая строка должна вернуть <code>stop-incomparable-adapter</code>, потому что D-представление изменяет значение через неописанное преобразование. Если запустить код на Node.js, получится проверяемый результат, но не тест трёх языков и не тест сетевого обмена.</p>\n<h2>Совместимость версий и правило изменения</h2>\n<p>Контракт начинает жить дольше одного примера, когда у него появляется владелец и политика изменений. Producer публикует версию и fixture. Каждый consumer проверяет известные версии на своих входах. Тест должен отличать добавление необязательного поля от изменения смысла существующего.</p>\n<p>Добавление нового поля обычно безопаснее, если старый consumer обязан его игнорировать и это правило записано. Переименование <code>amountMinor</code>, изменение единицы или превращение <code>null</code> в допустимый ноль — уже изменение смысла. Для такого шага нужна новая версия либо явная миграция. Поле <code>metadata</code> не должно становиться складом неоговорённых исключений.</p>\n<p>Полезно держать отдельные fixtures для нормального результата, отказа, неполного объекта и неизвестной версии. В каждом fixture фиксируются вход, ожидаемый status и причина. Тогда изменение адаптера вызывает понятный diff теста, а не спор по логам после выката.</p>\n<h2>Симптом → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Рабочая диагностика boundary contract</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Пропущенная сумма стала нулём</td><td>Сверить tag, наличие поля и единицу</td><td>Вернуть отказ или ввести отдельный вариант отсутствия</td></tr><tr><td>Интерфейс видит успех, worker повторяет операцию</td><td>Сравнить <code>outcome.kind</code>, <code>error.code</code> и <code>retry</code></td><td>Сделать решение явным и проверить идемпотентность отдельно</td></tr><tr><td>Лог D не находится по запросу PHP</td><td>Проверить общий <code>correlationId</code> на каждом переходе</td><td>Добавить идентификатор в новую версию и прокинуть его без замены</td></tr><tr><td>Одинаковое время даёт разные выводы</td><td>Сверить <code>time.basis</code> и обе точки интервала</td><td>Не вычислять latency из логических ticks</td></tr><tr><td>Один адаптер «почти» совпал</td><td>Проверить mapping на <code>exact</code></td><td>Описать преобразование отдельным правилом либо остановить обмен</td></tr></tbody></table></div>\n<h2>Порядок внедрения</h2>\n<ol><li>Назвать одну операцию и владельца её смысла.</li><li>Выбрать версию и выписать обязательные поля: tag, единицы, outcome, time и correlationId.</li><li>Зафиксировать допустимые значения и точные stop reasons для неполного и неизвестного входа.</li><li>Собрать по одному fixture на accepted, rejected, missing field, wrong unit и incompatible mapping.</li><li>Реализовать адаптеры так, чтобы каждое преобразование было видно в коде и тесте.</li><li>Проверить сериализацию: уникальные имена, допустимые JSON-значения, диапазоны чисел и кодировку.</li><li>Проверить цепочку на реальном стенде отдельным тестом: транспорт, права, повтор, корреляцию и наблюдаемость.</li><li>Только после этого обсуждать нагрузку, задержку и готовность выпуска. Boundary-validator сам по себе этих свойств не измеряет.</li></ol>\n<h2>Ограничения применимости</h2>\n<p>Пример намеренно мал. Он не проверяет ABI, сериализацию конкретной библиотеки, кодировку транспорта, версии PHP/Node/D, схему базы, права, таймауты, повтор после частичного побочного эффекта, безопасность, нагрузку или SLA. Он также не показывает, что три компонента действительно обменялись данными. Для этого нужны реальные точки входа, тестовый стенд, логи или трассировка и известный владелец результата.</p>\n<p>Фиксированные logical ticks нельзя превращать в latency, а <code>correlationId</code> — в доказательство доставки. <code>amountMinor</code> с валютой не заменяет правила округления, возврата и финансового учёта. Envelope с <code>retry: never</code> не доказывает идемпотентность операции. Эти свойства должны пройти свои проверки на уровне продукта.</p>\n<p>Если контракт должен поддержать иной результат, другую шкалу времени или новый способ обработки ошибки, это не повод молча ослабить validator. Добавьте поле, версию и fixture, затем повторите проверку. Fail-closed путь сохраняет неизвестное состояние видимым для владельца и не выдаёт удобное значение за подтверждённый смысл.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Граница подготовлена к следующему инженерному тесту, если независимый разработчик может взять fixture и получить тот же status без доступа к истории переписки. У записи есть одна операция и версия; результат имеет tag и единицы; outcome отделён от result; time имеет basis и две упорядоченные точки; correlationId сохраняется; каждый адаптер проходит exact mapping; отрицательные варианты возвращают конкретные stop reasons.</p>\n<p>После этого ещё нельзя писать, что PHP, JavaScript и D совместимы вообще. Можно сказать только: фиксированная запись соответствует выбранным правилам и готова перейти к отдельной проверке транспорта и среды. Такое утверждение уже достаточно полезно: оно показывает, что проверено, где заканчивается доказательство и какой следующий эксперимент нужен.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://www.rfc-editor.org/rfc/rfc8259\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format</a> — нормативное описание типов JSON, объектов, уникальности имён, чисел и требований к обмену.</li><li><a href=\"https://www.php.net/manual/en/language.exceptions.php\" target=\"_blank\" rel=\"noopener noreferrer\">PHP Manual: Exceptions</a> — официальное описание throw/catch, подъёма исключения по стеку и обработки необработанного исключения.</li><li><a href=\"https://262.ecma-international.org/16.0/index.html\" target=\"_blank\" rel=\"noopener noreferrer\">ECMAScript 2025 Language Specification, 16th edition</a> — официальное описание Completion Record с normal и throw completion.</li><li><a href=\"https://dlang.org/spec/errors.html\" target=\"_blank\" rel=\"noopener noreferrer\">D Programming Language: Errors</a> — официальное описание исключительной обработки D и размотки стека до обработчика.</li></ul>"
}