Architecture guide

Keep the commerce core
independent of providers.

The architecture should make payment, shipping, ERP and presentation technologies replaceable without rewriting order rules.

TH / DOCS
Principle→Boundary→Verification
implementation guidance · not a public API guarantee
01 / DOMAINS

Separate commerce responsibilities

Catalog, pricing, cart, checkout, payment state, order state and fulfillment have different failure modes. Keep their ownership explicit.

02 / ADAPTERS

Translate at the edge

Provider-specific payloads belong in adapters. The core should consume normalized commands and events.

Gateway callback ↓ verify signature / idempotency Payment adapter ↓ normalized event Order domain
03 / LEGACY

Modernize without forcing a big bang

A compatibility layer can preserve existing URLs, payloads or jobs while internals move behind a cleaner service boundary. Remove compatibility code only after production consumers are measured and migrated.

Project-specific contracts win.

These pages describe Thonem implementation patterns. Exact endpoints, payloads, credentials, retry rules and provider capabilities must be taken from the deployed project and its provider documentation.