---
id: ADR-COM-ORD-001
title: Five service modules realise Orders
product_area: commerce
module: orders
revision: 1
status: proposed
design_intent: proposed
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  macroservice-libraries: 54536a441935c6e09fdb7f96f0bec71c52ba4e03
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
decision: >-
  Keep the registered Orders scope over five service modules sharing Commerce persistence, with four HTTP APIs
  and a separate participant registration function.
constrains:
  - SVC-COM-ORD-checkout
  - SVC-COM-ORD-orders
  - SVC-COM-ORD-participants
  - SVC-COM-ORD-entitlements
  - SVC-COM-ORD-purchasing
  - RESP-COM
  - DOM-COM-ORD-006
origin: 'rhythm-v2-docs:specs/PRODUCT-AREAS.md#MOD-COM-ORD; OQ-COM-ORD-004 (purchasing home, open)'
alternatives:
  - option: Give checkout and placed sales separate corpus homes
    why_not: The shared placement responsibility would span two corpus homes without changing the underlying commit.
  - option: Relocate acquisition records to fulfilment before its ownership decision
    why_not: 'Purchasing ownership remains undecided, so the design retains its registered scope.'
consequences:
  - 'Checkout hosts placement while its transaction writes sale, fulfilment and redemption records.'
  - Purchasing keeps its current boundary until the ownership question is answered.
  - >-
    The four API facets have separate functions, logging and permission keys; registration uses invocation
    authority.
supersedes: []
evidence:
  - 'services-commerce at c8b66a98: modules/*/aws/*.module.ts; aws/commerce.service.ts; README.md.'
---

# Five service modules realise Orders

## Context

The product registry groups cart, sale, selling declarations, rights and acquisition costs together. Purchasing's future home remains open.

## Decision

The design retains the registered five-module boundary. Shared persistence supports in-process coordination, while each service facet retains its record ownership.

## Alternatives Considered

Separating checkout from sales would divide their placement responsibility without changing the shared transaction. Moving purchasing now would anticipate an unanswered ownership decision.

## Consequences

The placement API commits several owners' records. A purchasing move would require coordinated registry, contract and ownership changes rather than silently relocating its artifacts.