The Module System

As mentioned above, the project's basic design is centered around the module and when possible each module's properties were grouped together as partitions.

Each module's table is typically made of the following columns:

• id (see nect page)
• registration columns
• free text columns
• measurement columns (typically numerical)
• limited selection columns (lookup tables, actual column values or booleans)

Less common partitionable properties were store externaly in a module_tags tables and module_tag_groups and are available via pivot tables.

The basic database schema to accomodate for this design is therefore (fauna example):

In the codebase, each module has its set of (Laravel) models, validators, query specifics, related permissions, etc., and corrosponding frontend stores, data structures and forms.

This design enables flexibility with regard to each module`s specific details and a modular software design that is easier to maintain. It also allows for a relatively easy incorporation of new modules into the project (see How to add a module section).