Layer

Layers are probably the most important record in the system (maybe layouts too). Realistically a layer is a definition of fields and the values for those fields.

Templates

A template stores the current valid field names and types for a layer. Templates can be versioned to allow for changes/tweaks while maintaining a history and allowing for consistency validation of older layer records.

Fields

There are a few fields that should be present on any and all layers:

• statuses - A list of valid statuses for a layer, the order of this list matters as an instance will be considered complete when it reaches the final status in the list.
• id - Each layer definition needs an id, also each layer instance should have a unique ID and a reference to the definition used to create/update it.
• team - A reference to the team a layer definition belongs to. This does not restrict viewership but facilitates prioritization of presentation etc. Based on team permissions this can also be used to determine who can edit the definition.
• definition - For a layer template this holds a JSON representation of the fields and their types.

Records

Records represent individual instances of a layer template. You could think of a template as a class and a record as an instance of that class.

Fields

A Record has the following fields:

• status - The current status of this layer.
• timestamps - This is a placeholder for a variety of columns, by default the traditional created_on and updated_on but also started_on and closed_on as these can be useful for metrics.
• id - Everyone needs an id, it let's you know who you are.
• story_id - The story id ties everything together. This identifies layers that are related and part of the same body of work.
• definition_id - The id of the template version this instance was created from. This is useful for identifying types for fields as well as valid status values.
• owner - The id of the user who is responsible for this layer instance
• values - The actual values that have been entered for the layer. This is a map (embedded schema) of field -> value pairs.

References/Links

Layers can also reference a field from another layer, this means that it is possible for a layer to want to present data from another layer. Ideally this data is not duplicated in the layer holding the reference. However, that would likely be more efficient when querying.

There is also the question of how references should behave if/when a layer is updated? If the referenced field is removed it is likely better to copy the data into the layer holding the reference and allow the layer owners to remove the field if it is no longer desired.

This means that layers need to be cognizant of their references and there needs to be logic to maintain consistency/integrity across layers in the event of a change. Similarly references should be to the current version of the referenced layer