Technical Documentation

Database and application server technical documentation for developers of the software.

As with many other business management systems, the Muse Systems Business Management System (MuseBMS) is a large, enterprise class system trying to solve many different problems in business computing. In an ideal world each distinct business problem would be solved by a dedicated application built for purpose. Taking this siloed approach, however, would result in pushing the complexity out of individual applications into a still more complex set of integration layers which would have to harmonize data, timing, and enforce controls across all applications used by the business. And this is the crux of why large, complex, and often times unwieldy enterprise business systems are created: it is less complex and unwieldy to solve these problems together than separately. Ultimately all of the individual and seemingly independent functions of a business must work in harmony and coordination with each other for the business as a whole to be successful and maximally efficient. The software a business uses should facilitate the cross business unit flow of information and allow for coordination of business activities that wouldn’t otherwise be possible without the software.

None of this is to say that we shouldn’t attempt to bring as much order as possible to the problem of enterprise software development; if we are to create a workable and maintainable business management system our efforts in this regard are essential. Herein we’ll document the technical aspects of the MuseBMS, but also put forth a larger set of principles by which we’ll organize our application in an attempt to make the entire system as manageable as possible.

Foundational Technologies

The application is built using a few core, widely available open source technologies which include:

  • PostgreSQL

    MuseBMS principally stores application data using the PostgreSQL Object Relational Database Management System (ORDBMS). There are incidental uses of other kinds of data management mechanisms, but for the most part these are bundled modules in the application programming environment (Elixir/BEAM) and are used to facilitate systems operations more than core application features.

  • Elixir

    The application server is written using the Elixir programming language. Elixir is a language which runs on the Erlang BEAM Virtual Machine, “known for creating low-latency, distributed, and fault-tolerant systems.

  • Phoenix Framework

    The Phoenix Framework is used to create complex, interactive web based user interfaces and APIs using Elixir.

  • Hugo & The Docsy Theme for Hugo

    This documentation is created using the Hugo static web site generator and the Docsy theme for Hugo. Our Elixir API documentation is create using Elixir’s ExDoc library.

Naturally there are many other libraries and technologies involved in supporting more specific or niche roles, but the three listed above are foundational technologies used in the MuseBMS.

High Level Architecture

This section describes the highest level concepts used to organize the software.

Source Code Organization

A discussion on how the MuseBMS source code is organized.

System Component Listing

Here we begin documenting the system in detail, moving away from purely conceptual discussions to examining more concrete implementation details.

Elixir Project Structure

Each of the application server code of the various Components, Subsystems, and Platforms making up the MuseBMS is implemented as independent Elixir projects, each of which is organized along lines which support our development philosophy. While our Elixir projects largely conform to the standard patterns used by most Elixir projects, there are nonetheless departures from convention which are worthy of discussion.

Trigger Naming Conventions

Database trigger and trigger function naming conventions not only serve the purpose of identifying specific triggers easily, but also in ordering trigger execution at runtime.

Build Processes

Overview of building various pieces of our application including application releases and documentation.

Development Testing Standards

As development proceeds, the need to test code under a variety of conditions exists. This document establishes certain minimum standards for development related testing.

Last modified September 28, 2023: Update Technical Book description text (f384a955)