A data domain (domain) is a defined grouping of properties to allow the users to view the data with a perspective that highlights the particular properties of the data. The data domain defines the model schema (model) and other properties for that specific focus. Common examples of data domains are customers, students, employees, parts and product orders.
YOUnite doesn't restrict the data architect to a single data domain such as customers (single domain MDM) but allows the architect to model for multiple types (customers, students, employees, parts, product orders, etc) as part of a single solution.
Once a version of a domain is created and its data records are loaded (or mapped in a federated model), it can be referenced by other data domains, adaptors and by API consumers as a source of truth. Domains have version numbers so that other domains, adaptors and applications can bind to a specific domain and version (e.g. students:v3). Data governance can designate data at specific adaptors as the master data and can control which zone has the appropriate ACLs to access and update it.
Domain Types
The data records for a domain can be stored either as:
MDM Data Store: When the domain data records are stored in YOUnite. This is used when the entire organization is comfortable or mandated to migrate a domain to a single store. The YOUnite data store is optimal for reference data such as a list of states countries, zip-codes, etc.
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*
Domain Model Schemas
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.
YOUnite allows the data architect to model for multiple domains (customers, students, employees, parts, product orders, etc) as part of a single solution.
Once a version of a domain is created and its data records are loaded (or mapped, in a federated model), it can be referenced by other data domains, adaptors, and API consumers as a source of truth. Domains have version numbers so that other domains, adaptors, and applications can bind to a specific domain and version (e.g. students:v3). Data governance can designate data at specific adaptors as the master data and can control which zone has the appropriate ACLs to access and update it.
Domain Types
The data records for a domain can be stored either as:
MDM Data Store: When the domain data records are stored in YOUnite. This is used when the entire organization is comfortable or mandated to migrate a domain to a single store. The YOUnite data store is optimal for reference data such as a list of states, countries, zip-codes, etc.
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*
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 the schema for a data domain; it defines the properties that make up the /defining the properties for the domain's schema. The root node of the model schema is the properties element. See Valid Property Names and Valid Types for ModelSchema Properties below.
...
The first step in creating a domain is to define the domain name. You will have to also define the new domain's type and the zone it is attached to or (its "owning zone"). If you do not define the type and owning zone, then YOUnite will be do it for you by default):
...
| property | required | valid values | description |
|---|---|---|---|
name | yes | Must be at least 3 characters long but no longer than 128. | The domain name. Must be unique to the entire YOUnite deployment since domains are typically shared. TODO NEED SOME DESCRIPTION OF VALID CHARACTER PARAMETERS. |
| description | no | 0 to 255 characters long. If longer it will be truncated. | A human readable description of the domain. |
zoneUuid | no | Owning zone's domain UUID | The zone that the domain, the domain's versions, and its data records will be tied to. If this is omitted the caller's current zone will be used. Note that the caller must have permissions to create a domain. |
domainType | no | MDM_DATA_STORE or FEDERATED | The domain type can be either: MDM_DATA_STORE, which is when the domain's data records are stored in YOUnite. This is used when the entire organization is comfortable or mandated to migrate a domain to a single store. MDM_DATA_STORE is optimal for reference data such as a list of states, countries, zip-codes, etc. FEDERATED domains do not store their data in YOUnite, but reference and update data on the systems in which it resides. Federated domains require adaptors, metadata, and governance configurations which that are covered in detail *TODO: TUTORIAL ON FEDERATED* |
The model is not created in this step. Models are tied to specific versions, which is covered below.
POST a Domain Version
With the domain in place, its first version can be created. The domain version defines the properties that make up the domain version's model schema. You may want to create a new version if you want to add more properties to the model, for instance. The domain version numbers are automatically generated and start with 1 and continue in ascending order.
The root node of the model schema is the properties element. See Valid Property Names and Valid Types for ModelSchema Properties below.
...
| property | required | valid values | description |
|---|---|---|---|
modelSchema | yes | See Model Schema Properties and Post a Domain below. | A JSON model describing the schema for the data domain; it defines the properties that make up the domains schema. The root node of the model schema is the properties element. See Valid Property Names and Valid Types for ModelSchema Properties below. |
| description | no | 0 to 255 characters long. If longer it will be truncated. | A human readable description of the domain version. |
displayProperty | yes | A valid model schema property name | A property defined in the modelSchema that acts as an index for the domain. The data values for the displayProperty must always be unique. See Retrieving Data Records; the Display Property below. |
uniquenessRules | no | One or more valid model schema property names | Required data and their associated rules that are cache'd to make sure cached to ensure duplicate data entries are not POSTed to the domain. This defaults to the displayProperty if it is not provided. See UniquenessRules Property below. |
...