Pattern for extensibility of "core domain objects" (aka "reference data")

As part of the rearchitecture, each of the core domain objects (Facility, Program, etc) should define a smaller set of properties than it does today, but support a built-in mechanism for implementation-specific extensions.

I can think of two approaches for this:

  1. Each of those tables (Facility, Program, etc) has one “extraData” column that stores json. (I understand that postgresql does this pretty well, though I’ve never tried it myself.) The REST API would be responsible for exposing these in the right way as part of the Facility/Program/etc resource.

  2. For each of those tables we have two additional tables, like FacilityAttributeType (defines a name and a datatype) and FacilityAttribute (a Facility, a FacilityAttributeType, and a value). The REST API is also responsible for exposing these in the right way as part of the resource. (This is the model OpenMRS uses, but it was also in the era before relational databases could support json columns.) A benefit is that it forces you to define an “attribute type” explicitly, whereas in the other approach the attribute type is implicitly defines as the keys of the extraData json field.

Any thoughts about this?

-Darius

PS- Hi all! I’m now part of this group. :slight_smile: