//////////////////////
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 * http://www.apache.org/licenses/LICENSE-2.0
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND,
 * either express or implied.
 * See the License for the specific language governing permissions
 * and limitations under the License.
//////////////////////

[[core-api-structure,Structure]]
= Structure =
Zest™ promotes a conventional view of application structure, that computer science has been using for decades.

The definition is as follows;

    * One Application per Zest™ runtime instance.
    * One or more Layers per Application.
    * Zero, one or more Modules per Layer.
    * Zero, one or more Assemblies per Module.

The principle of this Structure is to assist the programmer to create well modularized applications, that are easily
extended and maintained. Zest™ will restrict access between Modules, so that code can only reach Composites and Objects
in Modules (including itself) of the same or lower Layers.

Each Layer has to be declared which lower Layer(s) it uses, and it is not allowed that a lower Layer uses a higher
Layer, i.e. cyclic references.

[[core-api-application,Application]]
= Application =
Every Zest™ runtime has _one and only one_ Application in it. It is possible to run multiple Zest™ runtimes in the same
JVM, and it is even possible to embed a Zest™ runtime within a Zest™ Application, but there can only be one Application
in a Zest™ runtime.

An Application is then broken into layers and modules are placed within those layers. Composites are placed within
modules. This forms the Application Structure and is enforced by the Zest™ runtime.

[[core-api-layer,Layer]]
= Layer =
A Zest™ Application must consist of at least one layer. More layers are common, often dividing the application along the
common architectural diagrams used on whiteboards, perhaps with a UI layer at the top, followed by a service or application
layer, then with a domain layer and finally some persistence layer at the bottom.

Zest™ enforces this layering by requiring the <<core-bootstrap-assembly>> to declare which layer uses which other layer. And
<<core-api-visibility>> rules define that layers below can not locate composites in layers above. Also, defining that
"Layer1 uses Layer2" and "Layer2 uses Layer3" does NOT imply that Layer1 has <<core-api-visibility>> to Layer3. If that
is wanted, then it must be declared explicitly.

[[core-api-module,Module]]
= Module =
Modules are logical compartments to assist developers in creating and maintaining well modularized code. A Module only
belongs to a single Layer, but many Modules can exist in the same Layer. Composite access is limited to;

    * Composites within the same Module, with Visibility set to Visibility.module (default).
    * Composites from Modules in the same Layer, with Visibility set to Visibility.layer
    * Composites from Modules in Layers below, with Visibility set to Visibility.application

Modules contains a lot of the Zest™ infrastructure, which are the enforcers of these wise modularization principles.

It is not possible to modify the Modules, their resolution nor binding in any way after the application starts.

[[core-api-visibility,Visibility]]
= Visibility =