A data domain (domain) refers to a data model, such as student or course, and is defined by the parties responsible for data governance. The data domain defines the model schema and other attributes for that focus. Common examples of data domains are customers, students, employees, parts, and product orders.  Data domains are typically created by the Data Governance Steward (DGS).

...

Federated: Federated domains do not store their data in YOUnite but retrieve and update the data on the systems in which it resides. For example, MIS, ERP, or CRM systems. Federated domains require adaptors, metadata, and governance configurations and are covered in detail *TODO: TUTORIAL ON FEDERATED*. Accessing federated data is covered on Accessing Data Records,

Domain Model Schemas

A domain Model Schema refers to the attributes (properties), format, and other metadata that defines how a specific domain should expect to store the data (either in the YOUnite Data Store or Federated), for the purposes of standardizing how data is exchanged between systems. The Data Governance Steward is responsible for configuring and maintaining domain model schemas. A  domain model schema is a JSON object describing/defining the properties for the domain's schema. The root node of the model schema is the properties element. See 949725525 and 949725525 for ModelSchema Properties below.

...

...

...

Each domain must have a duplicate detection property (fastDuplicateDetectionProperties). Fast Duplicate Detection Properties (FDDPS) are attributes of a domain and identify those fields that, when combined, MDM should use to detect whether the data record is unique. Refer to Domain Uniqueness, Deterministic Uniqueness, and Probabilistic Uniqueness for more information.

...

Fast Duplicate Dectection Properites Rules

Fast Duplicate Detection Properties are attributes of a Domain and identify those fields that, when combined, MDM should use to detect whether the DR is unique. Refer to Domain Uniqueness, Deterministic Uniqueness, and De-Duplication for more information.

• The value provided for the displayProperty must be unique between all domain entries of a given domain type (e.g. each entry in the "state" domain must have a unique stateName).
• Only one property in a domain can be the displayProperty. If more than one property is required to ensure uniqueness see the Uniqueness Rules Property below.
• Display properties are limited to type STRING.
• Properties designated as the displayProperty are required; i.e. null values are not allowed.
• Display properties are case sensitive e.g. "California" is NOT equal to "california".

...

Note: Updating arrays can be handled differently when the domain is federated and an "Array Advisory Practice" should be developed by the ZDS/DGS and communicated to developers.

For example, this can be illustrated using an  array of phone numbers… e.g. mobile, home, work, home-fax, etc.

When an adaptor detects a change in a source entities' array of phone numbers, it can send up the entire array or just the modified phone number in the array. In either case, the router will forward it based on the ACLs. The recipient can take these changes and add or update existing entries based on the phone number type property.

Since adaptor developers can handle arrays in one of these two different ways, it is recommended that the ZDS/DGSs make a decision about the preferred method, an "Array Advisory Practice," and communicate this to the adaptor developers.

Data Governance (DG) may say:

Never send a partial array of phone numbers but only the entire set so the entire set at the receiving adaptor can do a complete delete and replace on all phone numbers.

— OR —

Just send updates to an array only and the receiving adaptors can process them as they see fit and handle them using an index (which would be an agreed-upon domain version property; in this example it would be “type” (phone number type)).

An example of a good way for DG to articulate this would be in the “description” field for the phone number array in the domain version modelSchema.

{
        "properties": {
                "name": {
                        "type": "string",
                        "min": 2,
                        "max": 80
                },
                "phone": {
                        "type": "array",
                        "minItems": 1,
                        "maxItems": 50,
                        "description": "An array of phone numbers - ADAPTOR DEV ADISORY - Sending/receiving individual phone numbers is OK - sending/receiving the entire list is not necessary ",
                        "items": {
                                "type": {
                                        "type": "string",
                                        "min": 2,
                                        "max": 80,
                                        "regex": "^[A-Za-z]+"
                                },
                                "number": {
                                        "type": "number",
                                        "min": 2,
                                        "max": 10
                                }
                        }
                }
        }
}

...