Domain Architecture for E-commerce
The domain chain is catalogue → cart → order → payment events → fulfilment. Products carry price and stock; the cart is a session-keyed record; checkout creates the order in a pending state and hands payment to the provider; only stored, idempotent payment events move it to paid. Stock is a counter on the product row adjusted by the same functions that create and cancel orders, so the shop’s two most-argued numbers — “what did we sell” and “what is left” — derive from one set of records.
Compliance, Data Residency & Governance
Commerce records carry consumer-law and bookkeeping weight: displayed prices must equal charged prices (guaranteed structurally when search, product pages, and checkout read one table), invoices and orders retain for their statutory years under the sweep’s declared fields, and refunds keep an approval trail. Customer data sits in the European zone, and erasure runs over subject fields with the retained-invoice exception expressed as data rather than as someone’s memory of the rules.
Commerce regulation is mostly about promises and records: the price displayed is the price charged, orders and invoices are retained and retrievable, refunds follow a trail, and customer data obeys the usual European duties of residency, erasure, and evidence. KERNSTACK’s shape supports those duties plainly — catalogue prices read live from one table (so search results cannot quote a stale price), order states derive from stored payment events, retention is declared per record, and the whole shop’s data sits in one European zone a merchant can name in their privacy documentation.
Operational Impact on the Software Lifecycle Cloud
The operational shift is the end of reconciliation theatre: the nightly “does the shop agree with the payment provider” question answers itself from stored events, fulfilment exceptions surface as tasks instead of angry emails, and peak-season changes (a new shipping rule, a returns flow) ship as reviewed diffs to the same project in November — carefully, because the plan shows exactly what will change.
Key Domain Entities & Workflows
- Primary E-commerce Data Entities: products, carts, orders, payment events, fulfilment tasks
- Governed Lifecycle Workflows: catalogue publish, checkout, refund approval, fulfilment exception, returns intake
- Integrated Platform Services: functions, tables, search, workflows
Compare this integrated blueprint with the general Ecommerce backend reference architecture or explore our European Sovereign Cloud guarantees.
Frequently asked questions
The provider’s stored raw events, keyed by their event ids, from which the paid state derives. A customer’s claim and the shop’s state are both checked against the same immutable intake — never against a status someone typed.
Webhooks are stored first and processed idempotently; retries land on the same event row. A provider retrying for two days cannot double-apply a payment, and your deploy windows stop being payment-risk windows.
Either. The backend’s APIs are the contract; the window — hosted platform or an app inside the project — consumes them unchanged. Owning the backend first is the deliberate order most merchants choose.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.