Bounded Context & System Boundaries

The Point of Sale (POS) domain operates as an edge/satellite bounded context within the Obelaw open-core ERP ecosystem. It governs high-velocity retail transactions executed at physical registers, including cashier shift sessions, cash drawer management, multi-tender payments, receipt issuance, and offline-first transaction capture.

By maintaining strict boundaries, the POS domain ensures that checkout speed, drawer accountability, and local store operations remain decoupled from central catalog management, procurement, warehouse execution, general ledger postings, and freight management.

---

1. Operational Scope

The POS domain is strictly responsible for the following retail frontline capabilities:

• Register / Terminal Management: Physical POS device registration, hardware mapping, store assignment, and operational status.
• Cashier Shift Sessions: Opening and closing of cashier work cycles, including opening float declarations, operator authentication, and session ownership.
• Cash Drawer Management: Opening float, cash drops/skims, petty expenses, mid-shift safe transfers, closing cash counts, and discrepancy tracking.
• High-Velocity Checkout: Barcode scanning, line item entry, modifiers, discounts, tax calculation, tender selection, change calculation, and receipt generation.
• Multi-Tender Payments: Split payments across cash, card, digital wallet, store credit, gift card, and other tender types.
• Receipt Lifecycle: POS quick receipts, transaction notes, voided line items, cancelled receipts, refunds, and return notes.
• Offline-First Operation: Local execution and queuing of transactions during network disconnection, with monotonic sequence tracking and eventual replay.
• End-of-Day Reconciliation: Shift-level aggregation of sales, refunds, tender totals, taxes, and drawer variances for downstream financial settlement.

---

2. Out-of-Scope Boundaries

To preserve domain purity and prevent architectural coupling, the POS context explicitly excludes the following business operations:

Out-of-Scope Concern	Correct Ownership	Rationale
Central product catalog metadata, pricing master data, and SKU enrichment	Product Information Management (PIM) / Catalog	POS consumes product and price snapshots; PIM owns canonical catalog data.
Bulk purchase orders, supplier contracts, and procurement approvals	Purchasing / Procurement	POS reports sales demand; Procurement owns inbound supply.
Warehouse putaway, bin-level picking, packing, and stock movements	Inventory / WMS	POS consumes store-level stock; WMS owns warehouse and bin operations.
Long-term customer credit accounts, accounts receivable, and ledger double-entry bookkeeping	Accounting / FMS	POS emits sales facts; FMS owns revenue recognition, tax liability, and GL postings.
Long-haul freight manifests, carrier selection, and route optimization	Transport / TMS	POS records customer delivery requests; TMS owns shipment execution.
Customer relationship nurturing, pipeline management, and campaign attribution	CRM	POS may identify customers; CRM owns relationship and loyalty campaigns.
Identity access management and employee payroll	Identity / IAM and HCM	POS references cashiers as session operators; IAM and HCM own credentials and compensation.

POS may emit events consumed by these contexts, but it never owns their workflows, master data, or ledger policies.

---

3. Context Mapping & Integration Relationships

The POS Bounded Context interacts with external contexts using explicit, formal DDD relationship patterns. This ensures that central system changes do not corrupt local checkout operations and that store-level events are correctly translated for downstream settlement.

Integrating Context	Relationship Type	Interaction Pattern	Business Purpose
PIM / Catalog	Upstream (PIM) to Downstream (POS)	Customer-Supplier	POS consumes product master, price lists, tax categories, and barcode-to-SKU mappings.
Inventory / WMS	Upstream (Inventory) to Downstream (POS)	Customer-Supplier	POS consumes store-level stock availability and floor stock buckets; WMS reacts to PosSaleCompleted for stock deductions.
Sales / OMS	Upstream (POS) to Downstream (Sales)	Customer-Supplier	POS emits completed sales for order history, fulfillment exceptions, and enterprise reporting.
Accounting / FMS	Upstream (POS) to Downstream (FMS)	Customer-Supplier	POS emits session closure facts for revenue, tax, cash, and variance journal postings.
CRM / Loyalty	Upstream (POS) to Downstream (CRM)	Customer-Supplier	POS emits PosSaleCompleted for loyalty point accrual and customer profile linkage.
Identity / IAM	Upstream (Identity) to Downstream (POS)	Customer-Supplier	POS authenticates cashier sessions against Identity policies.
Payments / Card Acquirer	Bidirectional	Partner	POS interfaces with payment terminals and digital wallets for authorization and settlement reconciliation.

Integration Responsibilities

• PIM / Catalog owns product definitions, barcodes, prices, and tax categories. It does not decide how checkout is executed.
• Inventory / WMS owns stock buckets, lot numbers, and physical movements. It does not calculate tender change or drawer variance.
• Sales / OMS owns order orchestration and fulfillment exceptions. It does not manage cash drawer floats.
• Accounting / FMS owns the General Ledger, revenue recognition, and tax liabilities. It does not issue receipts or open cashier sessions.
• CRM / Loyalty owns customer profiles, points, and engagement. It does not slow down checkout speed.
• Payments / Card Acquirer owns authorization, capture, and chargeback workflows. POS integrates but does not replace acquirer systems.

---

4. Domain Isolation & Anti-Corruption Layer (ACL)

POS operates as an edge subsystem with its own local state, but it communicates with central systems asynchronously through domain events and lightweight polymorphic references. It never holds direct foreign keys to central ERP tables.

Zero Direct Database Mappings

• No Shared Foreign Keys: POS tables (Terminals, Sessions, Drawers, Receipts, Tender Lines, Cash Movements) contain no foreign keys pointing directly to central product catalogs, warehouse bins, GL accounts, customer master records, or sales order tables.
• Polymorphic Reference Mappings (Morph Aliases): Relationships to external documents are linked using generic, string-based polymorphic fields (Source Type and Source Alias). A POS receipt may reference a CustomerProfile, a SalesOrder, or a LoyaltyAccount without database-level coupling.

The Anti-Corruption Layer (ACL) Translation Engine

The ACL acts as a bidirectional translator on the context boundary:

1. Inbound Translation (Product Snapshot → POS Product DTO): Translates central product master, price, tax, and barcode data into a lightweight local cache format optimized for high-speed scanning.
2. Inbound Translation (Store Stock Snapshot → Availability DTO): Converts central inventory availability into a local stock indicator without exposing warehouse topology.
3. Inbound Translation (Customer Alias → POS Customer DTO): Looks up customer identity for loyalty or store credit without direct dependency on CRM tables.
4. Outbound Translation (PosSaleCompleted → Inventory Deduction Request): Translates receipt line items into WMS stock deduction instructions for the store location.
5. Outbound Translation (PosSessionClosed → Financial Settlement Payload): Translates session aggregates into FMS journal voucher instructions for revenue, cash, tax, and variance accounts.
6. Outbound Translation (PosSaleCompleted → Loyalty Accrual Request): Translates sale facts into CRM loyalty point accrual payloads.

Because the ACL owns all cross-boundary translations, changes to PIM, Inventory, Sales, FMS, CRM, or Identity schemas do not force changes to POS terminal logic.

Edge Autonomy

The POS subsystem is designed to operate autonomously during network disconnection:

• Local product cache supports barcode lookup and price calculation.
• Local transaction queue records sales with monotonic sequence numbers.
• Local drawer state tracks cash floats, drops, and petty expenses.
• On reconnection, queued transactions are replayed to central systems in sequence order.

This edge autonomy is bounded: product and price updates, stock reservations, and centralized settlement occur asynchronously once connectivity is restored.