Deployment Design

How to create a Registry Deployment for a target Domain

Let's say we need to deploy a Household Registry and we have ascertained that we need to have two Registers in the Registry

  1. Household Register

  2. Individuals Register

In addition to these two Registers, let's say, we also need to capture the vehicles that are owned by the Individuals.

If Vehicles are only additional peripheral information and does not involving allocating a functional ID to every Vehicle, the Vehicle information store (table) is just a simple table (where one individual can have multiple vehicles), instead of being configured as a "REGISTER"

  1. Vehicles Table

1. Create a Household Registry Extension Pack

Fork the repo - https://github.com/OpenG2P/openg2p-registry-gen2-extensionsarrow-up-right

There are reference implementations (farmer_extension) available here. Create a suitable folder here, in our case - "household_extension"

2. Define ORM models for the identified Registers and Tables

Target folder openg2p-registry-farmer-extension/src/openg2p_registry_farmer_extension/register_domain

The ORM Model defines how a domain entity is persisted in the registry database. It specifies the fields, identifiers, and relationships that represent the entity in storage.

Define ORM models to establish the database structure for the registry records, enabling the platform to store, retrieve, and manage the entity data.

G2PRegisterHousehold

class G2PRegisterHousehold(G2PRegister, G2PGeo): 
tablename = "g2p_register_households"

Here, G2PRegister is a base class that needs to be extended by all REGISTER Classes

G2PRegister brings the following attributes into the inherited REGISTER Class

The G2PRegisterHousehold class needs to extend G2PGeo, if the Household register has address attributes.

G2PRegisterIndividual

The G2PPerson abstract class brings the following attributes into the Register.

G2PTableVehicles

Since, we are treating vehicles as just a table of attributes for an individual, we only extend G2PTable and not G2PRegister. Any store, where we are not managing functional IDs, where there is no formal registry functionalities required, we can consider using G2PTable rather than G2PRegister. The G2PTable brings the following attributes

3. Define ORM Models for version histories of Registers and Tables

G2PRegisterHistoryHousehold

G2PRegisterHistoryIndividual

G2PTableHistoryVehicle

4. Define Pydantic models for Registers and Tables

5. Define Pydantic models for version histories - Registers & Tables

6. Define Service class for Registers & Tables

7. Naming convention - models, tables and services

8. Database scripts

  1. registry-configurations

  2. register_metadata

  3. lookup-data

  4. registry-inbound-message-rules

  5. registry-outbound-messages-templates

  6. data-models

  7. register-data

9. Databse scripts for master-data-service

Last updated

Was this helpful?