Open Domains

Domain Engineer

1. An individual or an organization who is an expert in a particular domain.
2. A “Domain Engineer” is the one who builds any or all of the following:
   1. A “data definition document” based on “Data Constructs”.
   2. A “domain definition document” based on “Data Constructs” and “Domain Constructs”.

UI Engineer

1. An individual or an organization who is an expert in defining user interfaces.
2. A “UI Engineer” is the one who builds a “ui definition document” based on “Domain Constructs” and “UI Constructs”.

Data Pipeline Engineer

1. The one who works on configuring and defining data pipelines.
2. A “Data Pipeline Engineer” is the one who builds a “data pipeline definition document” based on “Data Constructs” and “Data Pipeline Constructs”.

Development Engineer

1. The member of a software team that works on “service implementation”.

Service Implementation

1. The underlying software system that is developed to fulfill the functionality included in a “service definition document”.
2. A “service implementation” can be implemented in two different ways:
   1. It can implement one or more “service definition documents”.
      1. For each “service definition document” it will also mention one or more version numbers of that “service definition document” that it supports.
   2. Or it can implement a particular version of “Open Domain Specification Standard”.
      1. Typically these are “zero code” or “low code” “service implementations”.
      2. This implies that this “service implementation” will work with any “service definition document” that is created against the given version of “Open Domain Specification Standard”.
      3. Along with the version number  of “Open Domain Specification Standard”, it can also mention the set of layers it implements:
         1. Ex: “Domain”, “Domain and UI”, “Domain and Data Pipes”.

Service Provider

1. A business or an individual who provides a “service implementation” as a service to the end users.

Test Data Provider

1. A business or an individual who can ingest large amounts of test data into a test environment of a “service provider”.
2. They can mention a set of “domains” and a set of “service definition documents” that they support.
3. Different parts of the data ingestion can be separately paced based on the configuration provided by the “service provider”.
4. This will be extremely useful for different purposes like load testing, stress testing, functionality testing, cost estimations etc.
5. Based on the domain of the target system and the configurations provided by the “service provider”, the “test data provider” has the ability to ingest anomalies so that the “service provider” can assess the functioning of different systems like “fraud detection”, “anomaly detection”, “alerting system” etc.
   1. The “test data provider” will have a mechanism to intimate about the anomalies ingested by them so that the “service provider” can cross check how the above mentioned systems reacted to those anomalies.

Open Domain Definition Validator

1. A software program, developed by FicusRoot, that will validate a “Open Domain Definition Document” against the “Open Domain Specification Standard” that it implements either before submitting to the marketplace, or on demand.