This project has retired. For details please refer to its Attic page.



The Polygene™ Core is composed of several artifacts described in this section.

The following figure show the Core artifacts alongside libraries and extensions, and, in green, typical applications artifacts. This is not a full code dependency graph but should give you a good overview of how the pieces fit together. Find out more about each of the Polygene™ Core artifacts below.

Figure 1. Polygene™ Core Overview

Core API

The Polygene™ Core API is the primary interface for client application code during the main execution phase, i.e. after the application has been activated.

Learn more

Core Bootstrap

Polygene™ has a distinct bootstrap phase, also known as the Assembly of an application, where the applications structure is defined programmatically. Once all the layers, modules and all the composite types in each module have been defined the model is instantiated into an application. This enables the entire structure system in Polygene, where types "belongs" to a module and visibility rules define default behaviors, enforcement of architectural integrity and much more.

Learn more

Core Test Support

Polygene™ comes with classes to help with testing. There is also some mocking support, to allow some of Polygene’s unique aspects to be mocked, but since Polygene™ is so flexible at a fine-granular level, we have found that mocking is seldom, if ever, needed.

Learn more

Core Extension SPI

The Polygene™ Core Runtime has a number of extension points, which we call the Polygene™ Core Extension SPI. These are defined interfaces used only by the Core Runtime and never directly by application code. Extensions are assembled in applications during the bootstrap phase.

Learn more

Core Runtime

Your code should never, ever, have a dependency on Polygene™ Core Runtime. If you think you need this, you should probably contact and see if your usecase can either be solved in a existing way or perhaps that a new Core Extension SPI is needed.

Learn more