The Module System

Each module's table includes the following columns. Required:

• ID (see next page)
• Name Optional (dependent on module definitions)
• Registration columns
• Text columns
• Numerical columns (e.g., measurements, counts)
• Specific string values (controlled by check constraints)
• Enums
• Lookup columns (to simple lookup tables)

Optional properties were stored externally in the [module]_tags and [module]_tag_groups tables and are made available via pivot tables.

Optional properties with related numerical values (think measurements) were stored externally in the pivot and [module]_onps tables (Optional Numeric Properties).

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

At the (backend) application level, each module has its set of configuration files, Request Forms (Laravel's Validation), and Models (Laravel's ORM classes). In addition, module-agnostic Request Forms, Controllers, and Services are located in the standard Laravel application folders. Module agnostic API endpoints serve as the gateway to these resources.

This design enables flexibility with regard to each module's specific details in a module-agnostic framework that is easier to maintain. It also allows for relatively easy incorporation of new modules into the project.