Bounded Context & System Boundaries

The Customer Relationship Management (CRM) domain operates as a dedicated bounded context within the Obelaw open-core ERP ecosystem. It governs the complete commercial relationship lifecycle—from anonymous prospect acquisition through qualified lead management, opportunity pipeline execution, centralized contact and account directory maintenance, marketing attribution, and customer support desk operations.

By maintaining strict boundaries, the CRM domain ensures that relationship data, engagement history, sales pipelines, and service commitments remain consistent, auditable, and decoupled from order execution, warehousing, billing, and logistics concerns.

---

1. Operational Scope

The CRM domain is strictly responsible for the following commercial relationship capabilities:

• Lead Acquisition & Capture: Recording inbound prospects from websites, campaigns, referrals, events, partner channels, and manual entry.
• Lead Enrichment & Scoring: Augmenting lead records with firmographic, demographic, and behavioral data; applying scoring models to prioritize follow-up.
• Lead Qualification & Disqualification: Converting scored leads into qualified sales prospects or archiving them with validated reasons.
• Contact & Account Directory: Maintaining a unified, deduplicated directory of persons (Contacts) and organizations (Accounts) with role, persona, and stakeholder mappings.
• Opportunity & Pipeline Management: Tracking commercial opportunities through defined pipeline stages with probabilities, values, expected close dates, and weighted forecasts.
• Marketing Campaign Attribution: Linking leads, contacts, and deals to campaigns, channels, UTM parameters, and customer acquisition cost calculations.
• Customer Support Desk: Managing helpdesk tickets, service level agreements, queues, priorities, escalation rules, and resolution workflows.
• Activity & Touchpoint History: Capturing calls, emails, meetings, notes, tasks, and support interactions against contacts, accounts, leads, deals, and tickets.

---

2. Out-of-Scope Boundaries

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

Out-of-Scope Concern	Correct Ownership	Rationale
Commercial order pricing rules, discount matrices, and order dispatching	Sales / OMS	CRM identifies opportunity value; Sales owns quote-to-order execution and dispatch authorization.
Physical warehouse picking, packing, bin allocation, and stock movements	Inventory / WMS	CRM may reference delivery addresses; WMS owns physical fulfillment execution.
General Ledger postings, accounts receivable journals, and debt collection	Accounting / FMS	CRM tracks deal value; FMS owns revenue recognition, invoicing, and receivables.
Direct shipment tracking, carrier selection, and route optimization	Transport / TMS	CRM records customer addresses; TMS owns shipment execution and tracking events.
Product catalog enrichment, SKU attributes, and inventory availability	Product Information Management (PIM) / Catalog	CRM consumes product references for opportunity lines; PIM owns canonical product data.
Identity access management, authentication policies, and user provisioning	Identity / IAM	CRM references users as owners or agents; IAM owns credentials and permissions.
Payroll, commissions calculation, and sales compensation plans	HCM / Compensation	CRM provides pipeline and win data; HCM owns compensation rules.

CRM may emit events consumed by these contexts, but it never owns their workflows, ledger policies, or physical execution.

---

3. Context Mapping & Integration Relationships

The CRM Bounded Context interacts with external contexts using explicit, formal DDD relationship patterns. This ensures that operational changes in upstream or downstream domains do not corrupt internal relationship logic.

Integrating Context	Relationship Type	Interaction Pattern	Business Purpose
Sales / OMS	Upstream (CRM) to Downstream (Sales)	Customer-Supplier	Sales reacts to DealWon to materialize draft sales orders and quotes.
Accounting / FMS	Upstream (CRM) to Downstream (FMS)	Customer-Supplier	FMS reacts to DealWon and account changes to establish credit parameters and customer master links.
Inventory / WMS	Downstream (CRM) to Upstream (WMS)	Conformist (via ACL)	CRM consumes inventory availability facts only for opportunity configuration; WMS owns stock.
Marketing Automation / Flowchat	Bidirectional	Partner	CRM dispatches leads and tickets to engagement tools and ingests campaign responses and chat transcripts.
Product Information Management	Downstream (CRM) to Upstream (PIM)	Anti-Corruption Layer	CRM maps opportunity product references to PIM product aliases without schema coupling.
Transport / TMS	Downstream (CRM) to Upstream (TMS)	Conformist (via ACL)	CRM passes delivery addresses; TMS returns shipment status events.
Support / Knowledge Base	Upstream (Support KB) to Downstream (CRM Helpdesk)	Customer-Supplier	Helpdesk consumes knowledge articles and solution templates to assist ticket resolution.

Integration Responsibilities

• Sales / OMS owns order pricing, quote conversion, dispatch promises, and fulfillment orchestration. It does not decide deal probability or pipeline stage.
• Accounting / FMS owns customer credit limits, receivables, revenue recognition, and ledger postings. It does not manage pipeline stages or lead scores.
• Inventory / WMS owns physical stock, availability, and warehouse movements. It does not manage contact records or opportunity values.
• Marketing Automation owns campaign execution, message delivery, and engagement capture. It does not own the canonical contact directory or pipeline.
• PIM owns product definitions and attributes. It does not own opportunity commercial terms.

---

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

CRM 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 Sales, Accounting, WMS, TMS, PIM, or Identity.

Zero Direct Database Mappings

• No Shared Foreign Keys: CRM tables (Leads, Contacts, Accounts, Deals, Tickets, Activities) contain no foreign keys pointing directly to sales orders, invoices, warehouse bins, GL accounts, shipment records, or user identity tables.
• Polymorphic Reference Mappings (Morph Aliases): Relationships to external documents are linked using generic, string-based polymorphic fields (Owner Type and Owner Alias). A Deal may reference a SalesOrder, a Quote, or a Campaign 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 (Inbound Channel → Lead DTO): Translates website form submissions, chat transcripts, event registrations, and partner referrals into standardized lead records with channel attribution.
2. Inbound Translation (Campaign Event → Touchpoint): Converts marketing automation events into CRM activity records linked to contacts or accounts.
3. Inbound Translation (Sales Order Event → Account Fact): Translates downstream sales events into account relationship updates without exposing order internals.
4. Outbound Translation (DealWon → Sales Order Draft Request): Translates a closed-won deal into a sales order creation payload, including account reference, product lines, and commercial terms.
5. Outbound Translation (Account Changed → FMS Customer Update): Translates account directory changes into customer master update instructions for credit and billing setup.
6. Outbound Translation (Ticket Escalated → Notification Dispatch): Translates SLA breach and escalation events into notification payloads for engagement tools.

Because the ACL owns all cross-boundary translations, changes to Sales, Accounting, WMS, TMS, PIM, or Identity schemas do not force changes to CRM internals.