ARTHandдизайн и цифровые продукты
AHSHOP

Отдельная торговая система · начинаем разработку

CAT-01CATALOGcontract CHK-01CHECKOUTboundary PAY-01PAYMENTSadapter DLV-01DELIVERYadapter UPD-01UPDATEScontrol CAT-01CATALOGcontract CHK-01CHECKOUTboundary PAY-01PAYMENTSadapter DLV-01DELIVERYadapter UPD-01UPDATEScontrol

Магазин
в одном контуре.

AHShop проектируется как отдельная система для продажи товаров: витрина, каталог, корзина, заказ, оплата и доставка работают в одном торговом контуре. Это не страница AHCMS и не склад плагинов — систему можно проверять, обновлять и откатывать.

Начать проект AHShop Посмотреть контур API

Ядро остаётся небольшим. Возможности подключаются явно.

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

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

Один поток.
Разные модули.

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

CATALOGplanned module

Товар, вариант, остаток и цена

event
catalog.item.changed
compat
CORE ≥ 1.0
state
contract first
CHECKOUTplanned module

Корзина, расчёт и подтверждение заказа

event
checkout.confirmed
compat
CATALOG ^1
state
contract first
PAYMENTSplanned module

Адаптеры способов оплаты и статусы

event
payment.authorized
compat
CHECKOUT ^1
state
contract first
DELIVERYplanned module

Расчёт, выбор и контроль отправления

event
fulfillment.dispatched
compat
CHECKOUT ^1
state
contract first
UPDATERplanned module

Манифест, проверка, активация и откат

event
module.release.applied
compat
CORE EXACT
state
contract first

Обновление должно уметь остановиться.

API обновлений проектируется не как кнопка «поставить последнюю версию», а как последовательность проверяемых переходов. Каждый переход оставляет результат, который можно прочитать до активации.

  1. 1
    Registry

    Ядро получает подписанный манифест релиза и фиксирует канал обновления.

  2. 2
    Verify

    Проверяются подпись, контрольная сумма, версия ядра и политика доступа.

  3. 3
    Resolve

    Граф зависимостей собирается до загрузки; конфликт версий останавливает релиз.

  4. 4
    Preflight

    Миграции, конфигурация и health checks выполняются в подготовленном контуре.

  5. 5
    Activate

    Релиз включается атомарно и получает наблюдаемый идентификатор.

  6. 6
    Observe / rollback

    Сбой проверки возвращает предыдущий код и совместимое состояние данных.

Покупатель видит путь.
Команда видит состояние.

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

Покупатель
  1. Выбор
  2. Корзина
  3. Оплата
  4. Получение
Команда
  1. price.resolved
  2. order.created
  3. payment.authorized
  4. fulfillment.closed

Сценарная модель · названия событий уточняются вместе с доменной моделью.

Контур API до первой строки Shop.

Не выпускаем модули раньше правил, по которым они живут. Сначала фиксируем границы, совместимость и восстановление; затем строим вертикальный сценарий от товара до заказа.

Versioning
/api/shop/v1 остаётся стабильным контрактом; несовместимые изменения получают новую версию.
Idempotency
Команды заказа, оплаты и webhooks используют ключи повторного выполнения без двойного эффекта.
Events
Модули связываются версионируемыми событиями, а не чтением чужих таблиц.
Permissions
Токены ограничиваются магазином, модулем и действием; служебные секреты не попадают в журнал событий.
Observability
Каждая команда получает request ID, а релиз — отдельный журнал preflight, activation и rollback.
Data changes
Миграция объявляет совместимый диапазон и отдельную стратегию отката до включения модуля.

Начинаем не со всего магазина. Начинаем с целого маршрута.

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

  1. 1Core + module contractреестр, события, совместимость
  2. 2Catalog + pricingтовар, вариант, остаток, цена
  3. 3Cart + orderидемпотентный вертикальный путь
  4. 4Updaterманифест, preflight, activation, rollback

AHShop · самостоятельная торговая система

Спроектировать первый маршрут