ADR-007 — Business Object Ontology¶
Status¶
Accepted
Context¶
"Business Object" is used informally in retail systems design to mean many different things: a database table, a microservice entity, a domain model class, or a UI data structure. UC-BoK needs a precise, vendor-neutral definition that can be consistently applied across all 15+ canonical retail processes.
Decision¶
UC-BoK adopts a DDD-aligned Business Object ontology defined in SPEC-007. A Business Object is a named, identifiable unit of retail business meaning that participates in one or more business processes.
The ontology classifies Business Objects into four archetypes:
| Archetype | Definition |
|---|---|
| Aggregate Root | The primary entry point for a cluster of related objects (e.g. Order, Customer) |
| Entity | An identifiable object with independent lifecycle (e.g. OrderLine, Reservation) |
| Value Object | An immutable, identity-less descriptor (e.g. Address, Money, Quantity) |
| Reference Data | A stable, shared lookup (e.g. Currency, Country, UoM) |
Rules:
- Every Business Object has a stable
kebab-caseid and a canonical display name. - Aggregate Roots are the primary nodes in the Knowledge Graph for cross-domain queries.
- Value Objects are never referenced directly by ID in relationships — they are embedded in their parent.
- Every Business Object must declare its lifecycle states (where applicable).
- Business Objects are vendor-neutral: they describe retail concepts, not database schemas or API models.
Consequences¶
catalogs/business-objects.yamlcontains only entities conforming to SPEC-007 archetypes.- Impact analysis queries traverse from Business Object → Process → Capability correctly.
- Vendor-specific data models must be mapped to UC-BoK canonical Business Objects — not the reverse.