The Module System

Each module's table includes the following columns:

• ID - See the IDs, Tags and Slugs section below
• Registration columns - columns required to identify an item. When using human readable composite primary key, they are the denormalized elements of that key.
• Free text columns
• Measurement columns - numerical (optional)
• Limited selection columns - enums, lookup columns, 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 allows 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.