Due to its heritage from SQL Ledger and the on-going process of rewriting the inherited code, the architecture differs between parts of the application: the old parts and the ones which have already been rewritten.
Overall, the application consists of five layers:
Recent releases add separation between business logic and process state with the latter being stored in the database and managed at the Perl layer. Other than that, it’s the Perl layer’s responsibility to forward web requests to the database and presenting the resulting data in response to the user interface. The original goal to reduce the Perl layer to be a “glue” layer between the web server and the database has been abandoned with the introduction of this additional (business process) layer.
The “database as storage” layer is responsible for storing data with consistency and integrity; to that extent (and much more than in SL) constraints and triggers have been implemented. An additional role for the storage layer is to enforce data access rules; i.e. to protect data from being accessed by unauthorized users.
The main difference between old and new coding paradigms is at the Perl application layer: older code generates HTML fragments while newer code delivers data through web services. As part of the on-going code restructuring, there’s a major effort to create a Representational State Transfer (REST) web service based APIs. The intent here is to facilitate integration with other applications used by businesses (both in the business itself or as provided by customers and vendors).