Reference Domain Object Model

From CDQ Wiki
Public:Reference Domain Object Model
Jump to navigation Jump to search

The Reference Domain Object Model (RDOM) is CDQ's technical standard for how its services structure, name and type the data: the centrally managed OpenAPI schemas behind CDQ's APIs, databases and integrations. It is the logical level below CDQ's conceptual data model, which defines what the data means and which domain owns it. The wiki documents the 501 concepts of the RDOM, one page per concept with its JSON paths, its parents and its children. The pages are generated from the RDOM in CDQ's metadata.

Root schemas

The RDOM has three root schemas, one for each resource CDQ's services exchange on its own: business partners, bank accounts and banks. A concept can appear in several of them. A bank account is a resource of its own and part of a business partner, and an address belongs to business partners and to banks. The concept page of such a concept lists all its JSON paths and all its parents. That is why the wiki shows Bank Account and Bank below Business Partner, while the RDOM also uses them as roots.

The arrows show where a root schema embeds another one, labelled with the JSON member. The diagrams below show the concepts directly below each root. Each box links to its concept page, which shows the next level.

Business Partner

$.businessPartner

Bank Account

$.bankAccount

Bank

$.bank

How the RDOM realizes the conceptual data model

RDOM stays as it is. The conceptual model defines what each thing means and which domain owns it. RDOM defines how CDQ's services name and structure the data. The two are linked concept by concept, so no RDOM schema has to change, and the business partner model, today derived from RDOM, keeps its roots.

The diagram links each entity of the conceptual data model, grouped by domain, to the RDOM concepts that realize it. Below the entity name is its realization pattern. Entities without a realization are left out.

Realization patterns

How RDOM realizes an entity follows one of six patterns. The examples all come from RDOM's business partner schema, the one schema realized today.

Pattern Meaning Example What the example shows
NATIVE The RDOM schema is the entity's home. Identifier (CDQ) $.businessPartner.identifiers[*], $.businessPartner.profile.relatedPersons[*].person.identifiers[*] realizes Identifier Every identifier in a business partner record is an Identifier record of that partner. Type, value and status are attributes of Identifier, and nothing needs translating.
EMBEDDED An entity of another domain, or a reference entity, appears as a copy inside a payload, without an identity of its own. Address (CDQ) $.businessPartner.addresses[*], $.bank.address, $.bankAccount.bank.address, $.businessPartner.bankAccounts[*].bank.address, $.businessPartner.relations[*].endNodeBusinessPartner.addresses[*], $.businessPartner.profile.relatedPersons[*].person.addresses[*] realizes Address in Location The address is copied into the partner record. Its address type (legal, invoicing, delivery) is not an attribute of the address: it carries the relationship Business Partner uses Address and its purpose. Bank accounts work the same way. Their nesting under the partner is the Account Holder Relationship, and the bank inside them is the Financial Institution.
SPLIT Several RDOM concepts together realize one entity. Identifier (CDQ) of a tax type and VAT Payer Status (CDQ) $.businessPartner.profile.vatPayerStatus realize Tax Registration RDOM has no tax registration concept. The tax number is stored as an identifier, and the VAT payer status sits in the partner profile. The conceptual model sees one Tax Registration with its number, jurisdiction and status.
RESTRUCTURED An RDOM concept means something else than its position suggests. Business Partner Type (CDQ) BP_ADDRESS realizes Site RDOM stores some addresses as business partners of their own, with the type BP_ADDRESS. Conceptually such a record is a Site, a place the partner operates, located at a Location. In the same way, the operational permissions of healthcare professionals are licences, so they realize a Certificate.
REFERENCED The entity has its own resource and id, and payloads point to it. none yet New product, certificate and site services follow this pattern. Their schemas enter RDOM as native realizations and are referenced from other payloads.
NOT_REALIZED No RDOM concept realizes the entity yet. Contract Legitimate until a service needs the entity. The schema then enters RDOM, designed from the conceptual model.

Entity by entity

20 of the 37 entities have an RDOM realization today. The realizations come from the data domains of the metadata. Each entity page lists them with RDOM realization (the pattern), RDOM concept (the concept page), RDOM path (the JSON path) and RDOM mapping (how the concept realizes the entity). The table collects them.

Entity Domain Realization RDOM concepts How it maps
Business Partner Business Partner NATIVE Business Partner (CDQ), Business Partner Category (CDQ), Business Partner Type (CDQ) One business partner record is one business partner, except records of type BP_ADDRESS, which realize sites., The categories tell a person from an organization. NATURAL_PERSON, REGISTERED_INDIVIDUAL and HEALTHCARE_PROFESSIONAL mark a person, COMPANY, COURT, HOSPITAL, PHARMACY and the other values mark an organization., LEGAL_ENTITY, ORGANIZATIONAL_UNIT, OPERATIONAL_ENTITY and BRAND say what kind of organization a business partner is. Units and brands are linked to their legal entity by business relationships.
Name Business Partner NATIVE Business Partner Name (CDQ) Name type, value, short name and language are part of the name.
Legal Form Business Partner EMBEDDED Legal Form (CDQ) A copy of the legal form with name, abbreviation, category and CDL ELF code. Conceptually the business partner refers to one legal form of the legal form metadata.
Identifier Business Partner NATIVE Identifier (CDQ) Type, value and status are part of the identifier. Its embedded issuing body is conceptually a business partner acting as issuing body, and the jurisdiction of the issuing body an administrative area.
Tax Registration Business Partner SPLIT Identifier (CDQ), VAT Payer Status (CDQ) The RDOM has no tax registration of its own. Tax numbers are identifiers of a tax type, which together with the VAT payer status of the partner profile realize the tax registrations., The VAT payer status realizes the status of a tax registration, together with the tax numbers among the identifiers.
Business Partner Status Business Partner NATIVE Business Partner Status (CDQ) Type, official denotation, valid from and valid until are part of the status. The RDOM keeps only the current status, not its history.
Classification Business Partner NATIVE Tag (CDQ), Business Partner Classification (CDQ), Minority Indicator (CDQ) Classification type, code, value and level are part of the classification., The minority indicator classifies a vendor by the minority group it belongs to, mainly for reporting in the United States., Tags classify a business partner by custom types and values.
Contact Point Business Partner NATIVE Website (CDQ), Phone Number (CDQ), Contact Email (CDQ) Each contact email is a contact point of the email channel., Each phone number is a contact point of the phone channel., Each website is a contact point of the website channel.
Business Relationship Business Partner NATIVE Business Partner Relation (CDQ) Start node and end node are the business partners the relationship starts from and points to. Class, type, started at and ended at are part of the relationship.
Certificate Certificate RESTRUCTURED Operational Permission (CDQ) Healthcare operational permissions are licences held by a person. Each is a certificate with a certificate scope covering the business partner, its practice locations are sites.
Certificate Scope Certificate RESTRUCTURED Operational Permission (CDQ) An operational permission covers the healthcare professional it belongs to, so it realizes a certificate scope covering that business partner.
Address Location EMBEDDED Address (CDQ) Every address realizes that the business partner uses the address, with the address type as purpose. Postal addresses such as PO boxes or CEDEX addresses stay plain addresses without a location.
Geolocation Location EMBEDDED Geographic Coordinates (CDQ) The coordinates embedded in an address realize the geolocation of its location.
Administrative Area Location EMBEDDED Administrative Area (CDQ), Country (CDQ), Jurisdiction (CDQ) The country embedded in an address is an administrative area., The regions and other administrative areas embedded in an address are administrative areas., The jurisdiction embedded in the issuing body of an identifier is an administrative area.
Site Location RESTRUCTURED Business Partner Type (CDQ), Address (CDQ) The RDOM defines BP_ADDRESS as an address treated as a dedicated business partner. Such a record is a site, operated by the business partner it belongs to and located at a location., A physical address that marks a plant, warehouse or practice can realize a site the business partner operates.
Bank Account Payment NATIVE, EMBEDDED Bank Account (CDQ) IBAN, BIC, the national identifiers and the country belong to the bank account, which carries its bank and its payees., The RDOM carries the bank accounts of a business partner as copies inside the business partner.
Account Holder Relationship Payment EMBEDDED, NATIVE Bank Account (CDQ), Payee (CDQ) A bank account nested under a business partner realizes that the business partner holds it., A payee is a business partner receiving payments to the bank account, referred to by its name and external id. It realizes the account holder relationship in the role of payee.
Financial Institution Payment NATIVE, EMBEDDED Bank (CDQ) The bank with its CDQ ID, names, identifiers such as BIC and national bank codes, address, contact and relations realizes a financial institution., The bank embedded in a bank account is a copy of the financial institution keeping it.
Bank Branch Payment EMBEDDED Address (CDQ), Bank (CDQ) The branch data of the bank embedded in a bank account realizes the bank branch keeping the account., The address of the bank embedded in a bank account is the address the bank branch is located at.
Payment Evidence Payment RESTRUCTURED Vendor Payment Summary (CDQ) First and last payment date and the number of payments summarize the payments to a bank account as evidence for its trust score, without the individual payments.

Not realized yet: Contract, Contract Party, Contract Item, Certification, Issuer, Location, Account Verification, Product, Material, Trade Item, Product Identifier, Product Attribute, Product Classification, Product Relationship, Bill of Materials, Product Partner Relationship and Material Site Assignment.


Where the link lives

The link lives on the entity pages, in the properties above. The RDOM concept pages stay as they are, generated from RDOM by the metadata sync, and already record the JSON path of each concept. From an entity, its RDOM concepts lead straight to the schema.

Consequences

  • Two sources of truth, each for its own concern. RDOM is the technical source of truth for schemas. The conceptual model is the source of truth for meaning.
  • Two completeness checks. An RDOM element without a concept is a modelling gap. An entity without a realization is not implemented in any schema yet, which is legitimate for most of Product and Certificate.
  • Model-first for new services. Product, certificate and standalone location services are designed from the conceptual model, and their schemas enter RDOM as native realizations.
  • Schema change on demand. An existing schema changes only when a service needs it, for example when site monitoring needs a Location identity. Until then the embedded address has no Location id, and the mapping says so.

All concepts

Retrieved from "https://meta.cdq.com/w/index.php?title=Public:Reference_Domain_Object_Model&oldid=346765"