Unified Commerce Principles¶
Purpose¶
This document defines the architectural principles that guide every decision within the Unified Commerce Body of Knowledge (UC-BoK).
These principles are normative and apply to all reference architectures, business capabilities, processes and application components described by the framework.
Principle 1 — Business Before Technology¶
Statement¶
Technology exists to enable business capabilities.
Architectural decisions SHALL always start from business objectives rather than implementation constraints.
Rationale¶
Retail platforms evolve continuously, while business capabilities remain relatively stable.
Principle 2 — Domain-Driven Architecture¶
Statement¶
Business domains are the primary decomposition unit of the enterprise.
Applications SHOULD align with business domains rather than organizational structures.
Domain Examples
- Customer
- Order
- Inventory
- Fulfillment
- Payment
Principle 3 — Capability First¶
Statement¶
Architecture SHALL be described in terms of business capabilities before application components.
Business capabilities define what the enterprise does.
Applications define how those capabilities are implemented.
Principle 4 — API First¶
Statement¶
Every business capability exposed to external consumers SHALL be accessible through well-defined APIs.
Implications¶
- Clear contracts
- Versioning
- Documentation
- Consumer independence
Principle 5 — Event Driven¶
Statement¶
Business events SHOULD be the preferred integration mechanism whenever asynchronous communication is acceptable.
Event Examples
- Order Created
- Inventory Reserved
- Payment Authorized
- Shipment Delivered
Principle 6 — Single Source of Truth¶
Statement¶
Each business object SHALL have exactly one authoritative owner.
System of Record
| Business Object | System of Record |
|---|---|
| Customer | CRM |
| Order | OMS |
| Inventory | Inventory Service |
| Promotion | Promotion Engine |
Principle 7 — Composable Architecture¶
Statement¶
Business capabilities SHOULD evolve independently.
Loose coupling SHALL be preferred over tight integration.
Principle 8 — Channel Independence¶
Statement¶
Business logic SHALL NOT depend on customer channels.
Channels consume business capabilities.
Examples of channels include:
- POS
- eCommerce
- Mobile App
- Marketplace
- Call Center
- Clienteling
- Self Checkout
Principle 9 — Store as a First-Class Citizen¶
Statement¶
A physical store is not merely a sales channel.
Within Unified Commerce it is simultaneously:
- Sales channel
- Fulfillment center
- Return center
- Customer service point
- Inventory location
Principle 10 — Customer Centricity¶
Statement¶
Every customer interaction SHALL contribute to a unified customer experience.
Customer identity, order history, loyalty and preferences SHOULD be consistently available across channels.
Principle 11 — Inventory Visibility¶
Statement¶
Inventory SHALL be visible independently from its physical location.
Inventory Locations
- Warehouse
- Store
- Dark Store
- Vendor
- In Transit
Principle 12 — Orchestration over Point-to-Point Integration¶
Statement¶
Business processes SHOULD be coordinated through orchestration rather than hardcoded point-to-point integrations.
Principle 13 — Technology Neutrality¶
Statement¶
UC-BoK defines concepts rather than products.
The framework intentionally avoids references to specific vendors or implementation technologies unless used as examples.
Principle 14 — Evolvability¶
Statement¶
Architectures SHOULD support incremental evolution without requiring full platform replacement.
Principle 15 — Measurable Architecture¶
Statement¶
Every business capability SHOULD define measurable outcomes through KPIs.
Examples include:
- Conversion Rate
- Fulfillment SLA
- Inventory Accuracy
- Net Promoter Score
- Order Lead Time
Summary¶
The principles defined in this document constitute the architectural foundation of UC-BoK.
Every subsequent document in the framework SHALL comply with these principles unless explicitly stated otherwise.
References¶
- UCBOK-000 — Project Overview
- UCBOK-001 — Meta Model