The Galacticus code was designed to be highly modular. Every part of it consists of a simple and well-defined interface into which an alternative implementation of a calculation can easily be added. For example, the code is currently designed for the standard cold dark matter cosmological model, but could be adapted to a warm dark matter by simply writing a small module that performs calculations of the warm dark matter mass distribution and including a few directives in the file that specify what this module does. Then it gets automatically identified and compiled into the code. This approach for just about every aspect of the code so that it is very flexible.

Similarly, the physical description of galaxies is extremely flexible. Each galaxy has a set of components which can be created/destroyed as needed, each of which has a set of properties. For example, one component is the dark matter, and it has properties such as mass, spin etc. A new component (e.g. a stellar halo) can then be easily added by writing a module which defines its properties and its interactions with other components (as described below). Also, because of the modular nature, any such module can be trivially replaced by another that performs the calculations differently if required.

The actual formation and evolution of galaxies – the real inner workings of the code – is treated by simply defining a set of differential equations for each galaxy. For example,the module handling the hot gas halo surrounding a galaxy defines an ordinary differential equation (ODE) which includes terms for both cosmological accretion and cooling. The galactic disk module defines an ODE for conversion of gas into stars. Then, these are all just fed in to an ODE solver and it evolves them to a specified accuracy. This removes the need for fixed timesteps adopted in similar models, means that cooling and star formation etc. are all treated simultaneously, and makes the whole approach quite clear. There are a couple of additional features needed - e.g. the modules can define “interrupts” so that the ODE solver stops – this can be useful if they need to create a new component (e.g. the first time gas cools and infalls it needs to create a disk component) or to handle discrete events (e.g. if a merger occurs the ODE solver is interrupted, the merger processed, and then the ODE solver starts up again), and they additionally to handle tasks such as storing the history of star formation (or other properties) of a galaxy if these are need to compute, for example, delayed metal production rates.