Package-level declarations

The order summaries in the service's memory, newest version first. The shop has no order history page, so the summaries are not served; a deployment that has one binds OrderSummaries to the store that page reads (a table written with ... WHERE version < :version, say), as this one keeps the newest version of each order.

The buyers' notifications written to the service's log: the shop sends no mail. A deployment binds BuyerNotifications to its mail or push service, passing the key on as the service's idempotency key.

The ranges of the order numbers in the service's memory, CosId's store type memory: the store of the memory backend, where the node keeps its log in its JVM too, so a restart starts both afresh. The postgres and mongo profiles keep the ranges in the service's own database instead (CosId's jdbc and mongo stores), where every node of the service reserves its ranges from the same rows. It leases no machine slots: the order numbers' generator is a segment, which needs none.

Who ships an order. An order is its buyer's: the buyer reads it, and the kernel keeps every other buyer from it. The orderingAuthorizer keeps the buyer from shipping it, which only an employee does, a tenant-level caller: in development, a Wow-User without a Wow-Owner; behind the CoSec gateway, a principal of the role employee. The order process's commands reach the order on the context's command topic, outside admission, and a service's call on the internal port is a service identity's: the authorizer refuses neither.

The eShop's ordering service on the Wow host: the host finds the order model and the sagas through eshop-ordering-domain's binding index and serves its routes on the public port and the cluster on the internal one. It runs on the memory backend by default and on PostgreSQL with the postgres profile (spring.datasource.*).