Представьте оформление заказа, при котором платёж прошёл успешно, но обновление заказа завершилось ошибкой. Клиент видит сообщение об ошибке и пытается снова. Тем временем у поддержки есть запись о транзакции, на складе нет подтверждённого заказа, а финансовому отделу нужно знать, должен ли клиент что-либо.

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

Архитектура должна отвечать на этот вопрос до того, как первая транзакция попадёт в продуктивную среду. Иначе платёжный код постепенно вбирает в себя восстановление заказов, правила подписок, корректировки счетов и решения по исполнению.

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

Начните с четырёх обязанностей, а не трёх

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

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

Приreviewing архитектуры платёжного шлюза дополняйте диаграмму компонентов картой решений: кто определяет сумму, кто запрашивает списание, кто фиксирует результат и кто разрешает следующее бизнес-действие?

Держите шлюз рядом с провайдером

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

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

Назначьте ему такие обязанности:

• Валидация запроса, обращённого к провайдеру
• Аутентификация коммуникации с провайдером
• Преобразование внутренних полей в специфичные для провайдера поля
• Проверка входящих уведомлений провайдера
• Сопоставление ответов с сохранением полезных деталей провайдера

Знание продукта остаётся за пределами этого контракта. Шлюзу не нужно понимать уровни лояльности, условия доставки, льготные периоды подписок или промо-наборы. Передавайте ему одобренную сумму, валюту, платёжную ссылку и необходимые данные о способе оплаты — а не правила, по которым они были сформированы.

Полезный вопрос при проверке: потребует ли изменение политики возврата изменений в коде шлюза? Если да, пересмотрите границу.

Дайте платёжным операциям отдельного владельца

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

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

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

Также следует разделять два вида повторов:

• Технический повтор: повторение коммуникации для той же задуманной операции в рамках определённых правил безопасности.
• Повтор списания: новая попытка взыскать непогашенный остаток.

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

Пусть биллинг решает, что причитается

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

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

Рассмотрим гипотетический счёт на $100 с кредитом на $30. Биллинг должен запросить оставшиеся $70.огда не следует просить шлюз восстанавливать этот расчёт из метаданных подписки.

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

Та же дисциплина применяется и после возврата. Платёжные записи устанавливают, что было возвращено через провайдера; биллинг определяет, какой счёт или корректировка баланса соответствует этому возврату.

Пусть заказы решают, что происходит с покупкой

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

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

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

Координируйте возвраты, не возлагая на одну систему все задачи

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

• Компонент возвратов или заказов одобрял возврат.
• Назначенный владелец коммерческих расчётов определял сумму к возврату.
• Платёжный сервис проверял историю платежей и применимые лимиты операций.
• Шлюз отправлял запрос провайдеру.
• Платёжный сервис фиксировал подтверждённый или неопределённый результат.
• Биллинг и заказы соответствующим образом обновляли свои записи.

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

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

Сделайте восстановление частью контракта

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

• Как идентифицируются повторные запросы
• Какой компонент владеет авторитетным состоянием
• Как обрабатываются запоздалые или дублирующиеся уведомления
• Что происходит, когда следующий компонент недоступен
• Как сотрудники расследуют неопределённые результаты
• Какие действия можно безопасно повторять

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

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

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

Проверяйте границы бизнес-изменениями

Перед утверждением архитектуры пройдитесь по нескольким изменениям:

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

Неожиданные межкомпонентные изменения рассматривайте как сигналы для проверки. Часть координации законна; необъяснимая связанность требует внимания.

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

Шлюз должен заканчиваться там, где заканчивается коммуникация с провайдером по платежам. Платёжный сервис должен владеть исполнением платежей и доказательствами. Биллинг должен владеть обязательствами и балансами. Заказы должны владеть покупкой и её исполнением.

Запишите эти обязанности в интерфейсы, процедуры восстановления и зоны командной ответственности. Одна лишь диаграмма их не разделит.