Год я разбираю причины отказов и правлю сервисы за API провайдера: приём онлайн-платежей, обновление реквизитов карт, уведомления. Поэтому на вопрос «какая у тебя целевая система?» я без колебаний ответил: «API приёма онлайн-платежей» — продукт, над которым работаю. Этот ответ провалил несколько проверок из моей процедуры, выведенной из руководства R1: я назвал класс продукта вместо экземпляра, описал способы создания вместо ситуаций эксплуатации и не показал надсистему. Но главная ошибка была ещё раньше — я не назвал проект: в проекте подключения продавца целевая система может находиться у него, хотя почти всю свою работу я делаю в системе провайдера.
Здесь я рассматриваю не развитие платформы, а подключение одного продавца к новому API; продавец М — псевдоним этого реального случая, а различимые детали обобщены. Проект начинается с решения подключиться и заканчивается, когда система продавца проводит реальные платежи без помощи сопровождения; фраза «API работает» эту границу не показывает. Отдельная диагностика или правка кода может быть успешной, даже если продавец не запустился, а проект подключения — нет. Поэтому наша система — развёрнутые сервисы провайдера, которые непосредственно меняет моя работа, а целевая система этого проекта — то, что должно заработать у продавца. Если бы проектом было развитие самой платформы, целевыми действительно могли бы стать сервисы провайдера.
Мой текущий кандидат — система приёма платежей продавца М; это аналитическое имя, а не выражение из языка продавца или стандартов. В рабочую границу входят управляемые продавцом поверхности оплаты — страница или контейнер формы, конечная точка возврата после переадресации и терминал, — а также бэкенд, хранилища транзакций и ссылок на учётные данные, входящий обработчик, носитель сверки, конфигурация маршрутизации и сотрудники платёжных операций в роли операторов. Сервисы провайдера, плательщик, платёжные системы, эмитент, банк продавца и прежняя платформа остаются в окружении, а торговая операция продавца — предполагаемая надсистема. Пока единство элементов поддерживают только три гипотезы: общая операционная ответственность продавца, сквозная идентичность продавца и платежа, а также согласование состояния транзакции между носителями; список и нарисованная рамка сами по себе отношения «часть — целое» не доказывают. Свойство предполагаемого целого — довести платёжную часть продажи до требуемого исхода с участием плательщика или без него и восстановить состояние после потерянного ответа.
Вложенность рамок показывает предполагаемый состав, а не вызовы между элементами — композиционный приём рисунка D.1 из ISO/IEC 15288:2002; сами элементы подписаны в нотации C4 (уровень 2): тип и назначение на каждом.
Состав рабочей границы
- поверхности оплаты — платёжная страница эквайрера, встроенная платёжная форма эквайрера, собственная страница продавца, терминал, адрес возврата после переадресации
- бэкенд с интеграцией — держит учётные данные API, собирает и отправляет запросы
- хранилище транзакций — собственные ссылки продавца и состояния транзакций
- хранилище учётных данных плательщиков — сохранённые карты, токены, профили, мандаты
- входящий обработчик — принимает уведомления, возвраты после переадресации, обновлённые реквизиты
- сверка — задача или человек, потребитель файлов отчётности
- конфигурация маршрутизации — какие способы оплаты кому предлагаются
- сотрудники платёжных операций продавца — в роли операторов, разбирают исключения
Система работает не только в момент, когда плательщик нажимает «Оплатить». При наступлении срока регулярного платежа бэкенд использует сохранённые платёжные данные без участия плательщика, а после перевыпуска карты должен сохранить обновлённые реквизиты, если они пришли в ответе провайдера. Квитанцию могут оплатить через несколько дней и на отличающуюся сумму, поэтому носитель сверки сопоставляет выставленное с фактически полученным; при потерянном ответе система восстанавливает исход по собственной ссылке на транзакцию, не рискуя двойным списанием слепым повтором. Польза возникает снаружи границы: плательщик получает товар или услугу, а продавец — выручку и работающий приём платежей, не создавая собственных эквайринговых сервисов и не подключаясь напрямую к каждой платёжной системе. Создатели различаются по функции: поставщик технологии публикует и версионирует контракты; интегратор строит поверхности оплаты, бэкенд и хранилища; эквайрер открывает промышленную эксплуатацию и выполняет расчёт; продавец выбирает способы оплаты, принимает конфигурацию и организует работу операторов.
Моя работа меняет сервисы провайдера и через них помогает создать или изменить систему продавца, но это разные системы. Так и разрешился парадокс: объект почти всей моей работы и объект, по готовности которого заканчивается проект подключения, — не одно и то же.
Итог
Подводя итог, я вижу два разных объекта: целевую систему и «нашу» систему.
- Целевая система — система приёма платежей одного продавца.
- Наша система — сервисы за API.
Первую я особо не выделял, так как разработчик обычно работает с постановкой задачи от продакта, и никак не взаимодействует с продавцом.
Вторую я выделял, так как весь мой рабочий день построен вокруг нее.
Что выношу на разбор
-
Отсутствие конкретных деталей. Я знаю конкретного продавца М, который начал использовать нашу систему и проводит реальные платежи, — но назвать его не могу: это конфиденциальная информация. Поэтому система указана не именем, а приметами,
по которым её можно узнать (переведена на новый API, один интернет-магазин, свой набор способов оплаты, переключена разом); о том, как она устроена, это ничего не говорит — устройство описано выше. Тест «экземпляр, а не класс» я прохожу, потому что знаю, о ком речь. У читателя этого знания нет: под те же приметы подходят десятки продавцов, и по тексту не отличить описание одной системы от описания класса
похожих. Ему остаётся верить мне на слово. -
Элементы системы. Всё, что делает восемь элементов одной системой, я вывел из опубликованных контрактов API и каталога вариантов использования, а не увидел на системе продавца М: в описании нет ни записанного переключения, ни зафиксированного регулярного платежа без плательщика, ни одной сверки. То, что я вижу по работе, в пост не попадёт по той же причине, что и имя продавца. Система распознана по описанию, не по наблюдению; к следующей версии нужны наблюдения, которые можно показать.
-
Имя — «система приёма платежей продавца М». Тесты оно проходит: это вещь, при «замри» она не исчезает, и слово не занято соседними смыслами. Но правило руководства «имя — из языка клиента» существует не из вежливости: имя, которого клиент не узнаёт, — предупреждение, что границу мог провести аналитик, а не найти в мире. У продавца есть слова для частей — сайт, эквайринг, учётная система — и для действия — «оформление заказа», — но нет слова для целого, которое я нарисовал. Это
значит одно из двух: либо целое реально и просто не названо у него, либо оно существует только в моём описании; пункты 1 и 2 не дают по одному тексту отбросить второе. Имени нет и у стандартов, которые я проверил: ISO/IEC/IEEE 15288 и 42010, ГОСТ Р 57193-2025 и ГОСТ Р 57100-2016, ГОСТ Р 51303-2023, 161-ФЗ, Правила платёжной системы «Мир», глоссарий PCI SSC (совета по стандартам безопасности платёжных карт) и отраслевой словарь платежей. Ближе всего — тот же глоссарий PCI SSC, с двух сторон: «система точки продаж» — оборудование и программы, которыми продавец принимает оплату, — и «среда данных держателей карт» — люди, процессы и технологии, через которые идут данные карт. Но первая описана вокруг магазина с
терминалами и кассами, а моя система принимает в основном онлайн; вторая — периметр безопасности, нарезанный по потоку карточных данных: только карты, и без маршрутизации и сверки, если они данных карт не касаются. А Правила «Мир» и вовсе относят устройства приёма к сети эквайрера — у продавца в их языке есть только имя стороны, ТСП. Я выбрал имя-вещь, и цена не косметическая: у читателя ещё один повод спросить, чья это система — моя или продавца. Потому и выношу на разбор. -
Есть альтернативный кандидат в целевые системы. Руководство в своём примере называет целевой системой телекома «сеанс связи» — не способность, а событие. Если идти по этой аналогии буквально, целевой здесь была бы покупка плательщика: вот эта покупка, в 17:33 такого-то числа. По тестам про эксплуатацию она сильнее моей системы: у неё есть экземпляр без всяких примет, сцена — и есть её определение,
надсистема — день торговли продавца, а цепочка доходит до конца — до плательщика с товаром.
Проигрывает она одному тесту, но главному для проекта подключения: целевая система — то, что проект поставляет и о чём договариваются все его стороны, а ни одно подключение не поставляет одну покупку — оно поставляет систему, которая потом проводит тысячи покупок. Поэтому покупка — целевая другого проекта, собственной торговли продавца, а система приёма платежей — целевая проекта подключения. Как
в примере с парком: сессия посетителя — целевая парка, турникет с софтом — целевая проекта установки. -
Остаётся один довод против, из руководства «Системное моделирование». Признак целевой системы-продукта: она обычно пересекает границу предприятия — её поставляют заказчику и вводят в эксплуатацию у него; подсистемы границу не пересекают и сами по себе в эксплуатацию не вводятся. У нас границу между провайдером и продавцом пересекают контракты и сервисы провайдера — их поставляют и вводят в эксплуатацию у продавца. Система приёма платежей продавца не пересекает ничего: она строится у продавца и остаётся у него. По этому признаку целевой выглядит продукт провайдера — то есть ответ нулевой версии. Мой ответ: признак написан для проекта поставщика — он находит то, что продают через границу, и находит верно: продукт провайдера, нашу систему. О целевой системе проекта подключения, которую назначает продавец, а не продаёт провайдер, он ничего не говорит. Но «не противоречит» слабее, чем «подтверждает»: поддержки моему выбору этот признак не даёт, и это самый сильный довод за старый ответ. Потому и на разбор.
Это нулевая версия целевой и «нашей» системы. Покритикуйте её — особенно выбор между «системой приёма платежей продавца М» и покупкой как целевой — и назовите наблюдение на работающем экземпляре, которое убедило бы вас, что я распознал реальное целое, а не собрал удобную аналитическую границу.
Источники и конфиденциальность. Граница восстановлена по опубликованным контрактам API и документации провайдера, ISO/IEC/IEEE 15288:2015 (4.1.46), рисунку D.1 из ISO/IEC 15288:2002, ГОСТ Р 57193-2025, 161-ФЗ (ст. 3, п. 20), закреплённой редакции руководства R1 и паттернам FPF B.1.2, A.14, C.13. «Продавец М» — псевдоним одного рабочего случая; имя и различимые детали обобщены или исключены, внутренние показатели, устройство команд и наблюдения за клиентской архитектурой не используются. Поэтому граница остаётся проверяемой гипотезой, а не описанием подтверждённого клиентского устройства.