## Core

### Overview

The Zest™ 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 Zest™ Core artifacts below.

Figure 1. Zest™ Core Overview

#### Core API

The Zest™ 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

Zest™ 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 Zest, where types "belongs" to a module and visibility rules define default behaviors, enforcement of architectural integrity and much more.

Learn more

#### Core Test Support

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

Learn more

#### Core Functional API

The Zest™ Core Functional API is a generic package to work with Iterables in a "functional programming language" style.

This package is completely independent of everything else in Zest™ and may be used on its own in any kind of environment such as Spring or Java EE applications.

Learn more

#### Core I/O API

The Zest™ Core I/O API tries to address the problem around shuffling data around from various I/O inputs and outputs, possibly with transformations and filtering along the way.

Learn more

#### Core Extension SPI

The Zest™ Core Runtime has a number of extension points, which we call the Zest™ 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 Zest™ Core Runtime. If you think you need this, you should probably contact dev@zest.apache.org 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