Bounded Context & System Boundaries

The Purchases & Procurement Management domain operates as a dedicated bounded context within the Obelaw open-core ERP ecosystem. It governs the complete lifecycle of acquiring goods and services from external suppliers, from internal demand capture to financial verification and vendor reconciliation.

By maintaining strict boundaries, the domain protects procurement commitments from uncontrolled mutation and ensures that downstream operational and financial contexts receive clear, event-driven signals.

---

1. Operational Scope

The Purchases & Procurement domain is strictly responsible for the following capabilities:

• Supplier Lifecycle Management: Registration, qualification, classification, performance tracking, and compliance status of vendor organizations.
• Purchase Requisitions (PR): Internal documents capturing demand for goods or services before any external commercial commitment is made.
• Requests for Quotation (RFQ): Tendering processes inviting selected suppliers to submit priced quotations for defined requirements.
• Purchase Orders (PO): Authoritative contractual commitments issued to suppliers specifying items, quantities, prices, delivery dates, and terms.
• Vendor Bills / Invoices: Supplier-generated financial claims matched against PO and receipt evidence before approval for payment.
• 3-Way Matching Governance: Verification that PO, Goods Received Note (GRN), and Vendor Bill align within defined tolerances before approval.

---

2. Out-of-Scope Boundaries

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

Out-of-Scope Concern	Correct Ownership
Physical warehouse receiving, storage bin allocation, or lot quarantine	Inventory / WMS
Physical stock valuation, moving average cost, or inventory ledger movements	Inventory / WMS
General Ledger journal entries, accounts payable posting, or period close	Accounting / FMS
Bank wire payments, treasury releases, or cash management	Treasury / Payments
Customer sales orders, pricing contracts, or receivables	Sales / CRM

Procurement may emit events consumed by these contexts, but it does not own their internal workflows.

---

3. Context Mapping & Integration Relationships

The Purchases & Procurement Bounded Context interacts with external contexts using explicit, formal DDD relationship patterns. This ensures that upstream demand or downstream fulfillment changes do not corrupt procurement commitments.

Integrating Context	Relationship Type	Interaction Pattern	Business Purpose
Sales / Planning Context	Upstream (Sales) to Downstream (Procurement)	Customer-Supplier	Procurement reacts to material demand plans and stock replenishment signals generated from sales forecasts.
Inventory / WMS Context	Upstream (Procurement) to Downstream (WMS)	Customer-Supplier	WMS reacts to PurchaseOrderApproved to stage receiving docks and expect inbound deliveries.
Accounting / FMS Context	Upstream (Procurement) to Downstream (FMS)	Customer-Supplier	FMS reacts to VendorBillMatched to post accounts payable double-entry journal items.
Treasury / Payments Context	Upstream (Procurement) to Downstream (Treasury)	Customer-Supplier	Treasury reacts to approved Vendor Bills to schedule supplier payments.

---

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

Purchases communicates with the rest of the ecosystem asynchronously through domain events and lightweight polymorphic references. It never holds direct foreign keys to operational tables owned by Inventory, Accounting, or Customers.

Zero Direct Database Mappings

• No Shared Foreign Keys: Procurement tables contain no foreign keys pointing directly to inventory lots, warehouse bins, customer profiles, or GL accounts.
• Polymorphic Reference Mappings (Morph Aliases): Relationships to external documents are linked using generic, string-based polymorphic fields (Owner Type and Owner Alias). A vendor bill line may reference a PurchaseOrder, SalesOrderDropShipment, or ReturnToVendor 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 (Demand Signal → Requisition DTO): Translates sales forecasts, minimum-stock alerts, or production plans into internal purchase requisition line items.
2. Outbound Translation (PO Approved → Inbound Receiving Expectation): Converts an approved purchase order into an expected receiving instruction consumed by the WMS context.
3. Vendor Bill Translation (GRN Event → Bill Matching Payload): Receives receiving evidence from WMS and translates it into quantities available for 3-way matching against vendor bills.

Because the ACL owns all cross-boundary translations, changes to the Inventory or Accounting schemas do not force changes to Procurement internals.