UC-BoK Meta Model¶
The Meta Model defines the fundamental building blocks of UC-BoK. Every concept in the framework belongs to exactly one meta-model element. It establishes the shared language for architects, analysts, developers, and business stakeholders.
Meta Model Layers¶
UC-BoK organises retail knowledge into six layers, from business intent down to technical execution:
-
1 — Business Domain
A coherent functional area of the retail enterprise.
Examples: Customer · Order · Inventory · Fulfillment · Payment · Pricing · Store
-
2 — Business Capability
What the business is able to do — stable, vendor-neutral, technology-agnostic.
Examples: Checkout · Inventory Visibility · Clienteling · Loyalty
-
3 — Business Process
How a capability is executed — involving actors, systems, and business rules.
Examples: BOPIS · Ship-from-Store · Clienteling Sale · BORIS
-
4 — Business Event
Something meaningful that happened. Past-tense, domain-scoped, integration-ready.
Examples:
OrderConfirmed·InventoryReserved·PaymentCaptured -
5 — Application Component
A deployable software system that implements one or more capabilities.
Examples: OMS · POS · WMS · CRM · CDP · Loyalty Platform
-
6 — API / Integration
The technical surface that exposes capabilities to consumers.
Examples: Create Order · Reserve Inventory · Calculate Promotion
Meta Model Relationships¶
| From | Relationship | To |
|---|---|---|
| Business Domain | owns | Business Capability |
| Business Capability | implemented through | Business Process |
| Business Process | exercises | Business Capability |
| Business Process | produces | Business Event |
| Business Capability | implemented by | Application Component |
| Application Component | exposes | API |
| Application Component | publishes | Business Event |
| Business Capability | measured by | KPI |
Supporting Elements¶
In addition to the six layers, UC-BoK models three supporting element types:
| Element | Purpose | Examples |
|---|---|---|
| Business Object | Named, identifiable unit of retail meaning | Order, Customer, Reservation, Basket |
| KPI | Measures effectiveness of a capability | Conversion Rate, Inventory Accuracy, NPS |
| Architecture Pattern | Reusable implementation approach | Event-Driven Architecture, CQRS, MACH, Saga |
Naming Rules¶
| Element | Convention | Example |
|---|---|---|
| Business Domain | Singular noun | Customer, Order |
| Business Capability | kebab-case stable id |
inventory-visibility, checkout |
| Business Process | Business-oriented name | Buy Online Pick-up In Store |
| Business Event | PascalCase past tense | OrderCollected, PaymentCaptured |
| Application Component | Product-independent archetype name | OMS, POS, SIM |
| API | Verb + noun | Create Order, Reserve Inventory |
Design Principles¶
- Vendor Neutral — no concept references a specific software product
- Technology Agnostic — architecture is independent of implementation technology
- Capability Driven — capabilities are the primary unit of architectural analysis
- API First — every capability is exposed through a well-defined API contract
- Event Driven — business events are first-class citizens, not afterthoughts
- Domain Driven — boundaries follow business domains, not organisational charts
- Business Centric — every element traces back to a business outcome