The Module System
Each module's table includes the following columns:
- ID - See the IDs, Tags and Slugs section below
- Registration columns - denormalized elements of the compound id primary key (optional)
- Free text columns
- Measurement columns - numerical (optional)
- Limited selection columns - enums, lookup columns, restricted column values, booleans (optional)
Less commonly-used properties were stored externally in the [module]_tags and [module]_tag_groups tables and are made available via pivot tables.
In the case of sparsely-used numeric measurements, optional numeric properties (onps) were stored externally in the [module]_onps tables.
The basic database schema to accomodate for this design is (lithics example):
At the (back end) application level, each module has its set of configuration files, Request Forms (Laravel's Authentication and Validation), and Models (Laravel's ORM classes). In addition, module-generic Request Forms, Controllers, and Services are located in the standard Laravel application folders. Module-Generic API endpoints serve as the gateway to these components.
This design enables flexibility with regard to each modules' specific details in a module-generic framework that is easier to maintain. It also allows for the relatively easy incorporation of new modules into the project.