Bounded Context & System Boundaries

The Accounting & Financial Management System (FMS) operates as the authoritative bounded context for recording, classifying, summarizing, and reporting the financial consequences of every economic event across the Obelaw ecosystem.

By maintaining strict boundaries, the domain protects the integrity of the General Ledger and ensures that financial statements remain auditable, immutable, and regulatorily sound.

---

1. Operational Scope

The Accounting & FMS domain is strictly responsible for the financial interpretation of enterprise activity:

• General Ledger (GL): The central book of accounts where all double-entry transactions are permanently recorded.
• Chart of Accounts (COA): The hierarchical directory of all accounts available for recording financial events.
• Balanced Journal Entries: Every journal voucher must satisfy the zero-sum rule before it can be posted to the ledger.
• Fiscal Period Governance: Definition, opening, closing, and locking of accounting periods and fiscal years.
• Financial Reporting: Production of the Trial Balance, Income Statement (P&L), Balance Sheet, and cash-flow-equivalent statements.

---

2. Out-of-Scope Boundaries

To preserve domain purity and prevent architectural coupling, the Accounting context explicitly does not manage the following concerns:

Out-of-Scope Concern	Correct Ownership
Physical cash drawer hardware and till operations	POS / Retail Operations
Customer invoice issuance, payment chasing, and debt collection workflows	CRM / Receivables Management
Physical warehouse valuation, lot costing, and stock movements	Inventory / Supply Chain
Supplier negotiation, purchase orders, and procurement approval	Purchasing / Procurement
Payroll computation, tax withholding, and employee benefits	HCM / Payroll

Accounting may consume events from these contexts, but it never owns their workflows.

---

3. Context Mapping & Integration Relationships

The Accounting & FMS Bounded Context interacts with external contexts using explicit, formal DDD relationship patterns. This ensures that operational changes do not corrupt internal ledger logic.

Integrating Context	Relationship Type	Interaction Pattern	Business Purpose
Sales / Billing Context	Upstream (Sales) to Downstream (FMS)	Customer-Supplier	FMS reacts to InvoiceCreated and revenue-recognition events to record receivables and revenue.
Purchasing / Procurement Context	Upstream (Purchasing) to Downstream (FMS)	Customer-Supplier	FMS reacts to approved bills and supplier liabilities to record expenses and payables.
POS / Retail Operations Context	Upstream (POS) to Downstream (FMS)	Customer-Supplier	FMS reacts to CashOnDeliveryCollected and till-settlement events to record cash and revenue.
Inventory / WMS Context	Upstream (Inventory) to Downstream (FMS)	Customer-Supplier	FMS reacts to consumption, receiving, and valuation events to record asset and COGS movements.

---

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

Accounting acts as an asynchronous subscriber to operational events. Operational domains publish business events such as InvoiceIssued, GoodsReceived, or CashCollected. Accounting listens to these events and translates them into balanced journal entries through a dedicated Anti-Corruption Layer (ACL).

Zero Direct Database Mappings

• No Shared Foreign Keys: The Accounting context contains no foreign keys pointing directly to sales orders, purchase orders, inventory lots, or customer records.
• Polymorphic Reference Mappings (Morph Aliases): Relationships to external documents are linked using generic, string-based polymorphic fields (Source Type and Source Alias). This maps a journal entry to a SalesOrder, PurchaseOrder, or ProductionTicket without database-level coupling.

The Anti-Corruption Layer (ACL) Translation Engine

The ACL acts as a unidirectional translator on the context boundary. It validates, translates, and maps operational event payloads into ledger-aware instructions:

1. Inbound Translation (Operational Event → Ledger Instruction): Translates external document identifiers and event metadata into debit/credit account allocations, cost center tags, and source aliases.
2. Payload Isolation: The ACL forwards only the minimal financial payload required to construct a journal entry. Operational internals such as product categories, carrier details, or customer loyalty tiers are never exposed to Accounting.
3. Event Replay Safety: Because Accounting rebuilds ledger state from posted journal entries rather than operational snapshots, historical events can be replayed through the ACL without corrupting current balances.