Business Objects

A Business Object defines canonical business information used by capabilities. It is application-neutral and is not an execution primitive.

Definition model

A canonical Business Object may define its identifier, business definition, JSON Schema, business keys and key scope, typed relationships, lifecycle/state dimensions, related capabilities, version and provenance.

abcs: "0.2"
id: procurement.purchase-order
title: Purchase Order
schema: schemas/objects/procurement/purchase-order.schema.json
keys:
  - name: purchase-order-number
    fields: [number]
    scope: [buyer]
relationships:
  supplier:
    target: procurement.supplier
    cardinality: one
  receipts:
    target: procurement.receipt
    cardinality: many

Business keys, not artificial global IDs

ABCS distinguishes the identity of an object type from the identity of a business record. procurement.purchase-order identifies the canonical object type. An individual Purchase Order may be identified by a business number scoped to a buyer or organization. ABCS does not require every enterprise record to acquire an artificial global UUID.

{
  "object": "procurement.purchase-order",
  "key": {
    "number": "4500012345",
    "buyer": "urn:example:walmart"
  }
}

Canonical fields

Canonical JSON property names and paths form the stable field vocabulary. Application Packs or other implementations map native application fields to those canonical paths. ABCS does not create separate field IDs for every attribute.

Reusable business primitives

Draft 0.2 introduces reusable schemas for Party, Identifier, Address, Monetary Amount, Quantity and Business Object Reference. These prevent Procurement, Finance, Sales and other domains from independently redefining the same business semantics.

Party and contextual roles

A Party may be an organization or person. Supplier, Customer, Buyer, Seller, Payer, Payee and Carrier are contextual business roles. A single organization can therefore participate in different domains without becoming unrelated canonical identities.

Multidimensional state

Complex business objects should not collapse independent state dimensions into one giant status value. The reference Purchase Order distinguishes lifecycle, approval, fulfillment and invoicing state.

{
  "status": {
    "lifecycle": "open",
    "approval": "approved",
    "fulfillment": "partially-received",
    "invoicing": "not-invoiced"
  }
}

Closed canonical schemas

Draft 0.2 canonical schemas are deliberately strict. Vendor-specific application fields, routing metadata and implementation details do not belong in canonical payloads. A future extension mechanism should be added only if practical implementations prove one is necessary.