There are a lot of concepts in Zest™ which may have different meanings in other contexts. So in true DDD-style ubiquitous language, we are here listing the definitions of the terms and concepts that are being used.
An Abstract Mixin is an implementation of the MixinType interface, but is an abstract class and has not implemented all the methods.
The Zest™ runtime can use multiple Mixins for each MixinType interface. It is also possible to let a Generic Mixin handle the remaining missing methods.
Abstract Modifiers are Modifiers that do not implement all the methods of the MixinType interface.
This works essentially in the same manner as the Abstract Mixin. And the methods that are not implemented will not be part of the Invocation Stack of those methods.
Application is the top level concept handled by the Zest™ runtime instance. It holds the information about the Layers in the application architecture. See Structure for more information.
There is one and only one Application instance per Zest™ Runtime instance.
During the Bootstrap phase an Application is given a Mode that can be test, development, staging or production.
See Assembly.
An Association is a reference to an Entity Composite.
References to Entities must be maintained in Associations. It is illegal to define a Property with an Entity Composite as its type.
A Composite is an instance of a Composite Type.
However, we often speak of Composites when we actually mean CompositeType, similarly as we often speak of objects when we really are talking of classes in OOP.
A Composite Context is a mechanism to separate the state of a TransientComposite across two or more threads. If a thread modifies a value, only that thread will see the changes, another thread will have its values protected by the thread boundaries. Use-cases for this include user credentials on which behalf the thread is executing.
There are 5 Composite Meta Types defined in Zest, which each share the composition features but have distinct semantic differences.
CompositeType is the Java interface that declares the composition, from which Composite instances can be created.
Composite Type interfaces must be a sub-type of one of the 5 Composite Meta Types defined in Zest™ otherwise it can not be instantiated.
A concern is a stateless Fragment, shared between invocations, that acts as an interceptor of the call to the Mixin. The Concern is a Java class, that either implements the MixinType it can be used on, or java.lang.reflect.InvocationHandler which allows it to be used on any arbitrary MixinType.
Concerns have many purposes, but they are not intended to produce side effects (see SideEffect). Use-cases involves;
Concerns are established by the use of the @Concerns annotation on composites.
Concern is one of the 3 kinds of Modifiers defined in Zest.
Service Composites can have configuration associated to it and that is done via Configuration Composites, which are a subtype of Entity Composite, as they are stored permanently in configured Entity Stores. Configuration Composites are also initialized automatically from properties files first time. Note that on consequent start-ups the properties file is not read, as the configuration is read from the EntityStore.
ConfigurationComposite is one of the 5 Composite Meta Types defined in Zest.
See Configure a Service to learn how to use Configuration Composites.
Constraints are a kind of validators, which are consulted prior to invoking the method call. Zest™ currently only supports ParameterConstraints on methods and value constraints on Properties, but future versions will include Constraint types for checking complete method calls and return values.
See Constraint for better understanding of its details.
See Constraints Library for ready to use Constraints.
See Create a Constraint to learn how to write your own Constraints.
Constraint is one of the 3 kinds of Modifiers defined in Zest.
An Entity Composite, or just Entity for short, is a persisted composite with an Identity. An entity only has scope within an UnitOfWork and is therefor inherently thread-safe.
EntityComposite is one of the 5 Composite Meta Types defined in Zest.
A part of the implementation of a Composite. There are 4 fragment types:
Generic Fragments are Fragments that implements java.lang.reflect.InvocationHandler and potentially capable of being used for all MixinTypes. This is the direct opposite of the Typed Fragments, which implements the MixinType interface.
A Generic Mixin implements the java.lang.reflect.InvocationHandler. The invoke() method will be called for all MixinType methods that the Mixin has been matched with, through the matching rules.
It is potentially possible that the Generic Mixin also implements the MixinType interface. In that case, the concrete methods will be called, but if the Mixin is also an abstract class, then the invoke() method will be called for the methods that has been match but are not present.
TODO
This term has no definition yet. Learn how to contribute in Writing Documentation.
For each method, Zest™ will create and re-use an Invocation Stack. It will be built with the sequence of Modifiers and an end-point that will link into the stateful Mixin.
It is important to recognize that, for memory footprint reasons, Invocation Stacks are shared across Composites of the same Composite Type. They are however thread-safe, in that Zest™ will never bind the same Invocation Stack to more than one Composite instance during a method call, but that between method invocations the Modifiers in the Invocation Stack can not assume that it is bound to the same Composite instance. Therefor, Modifiers are not expected to keep state between method invocations, and when it needs to do that, then it should reference a Mixin via the @This annotation. Zest™ will during the binding of the Invocation Stack to the Composite, also ensure that all referenced Mixins are correctly injected in the Invocation Stack.
Zest™ promotes a Layered application design, where Layers can only access lower Layers and not higher Layers or Layers at the same level.
TODO
This term has no definition yet. Learn how to contribute in Writing Documentation.
TODO
This term has no definition yet. Learn how to contribute in Writing Documentation.
The Mixin is the instance providing the stateful representation of the MixinType. This can either be a class implementing the MixinType or a java.lang.reflect.InvocationHandler that is generic to handle any or a subset of MixinType.
The MixinType is the static type of a part of the Composite. The MixinType is an interface that defines the methods to be exposed in the Composite.
Modifiers are stateless interceptors of method calls, that forms an Invocation Stack. The top of the Invocation Stack is linked to the Composite invocation handler and the bottom of the Invocation Stack is linked to the Mixins. Invocation Stacks are shared, so Modifiers must assume that the member fields will only be valid within a single method invocation.
There are 3 kinds of Modifiers;
Modules defines the scope of the Composites. Modules are wired with Assemblies, and can expose Composites as visible. Non-visible Composites are not reachable from other Modules.
TODO
This term has no definition yet. Learn how to contribute in Writing Documentation.
When a @This injection refers to a MixinType which is not extended by the Composite Type the former becomes a private MixinType.
TODO
This term has no definition yet. Learn how to contribute in Writing Documentation.
See the Leverage Properties how-to.
Service Composite is a subtype of Composite, and has a range of features built into it.
ServiceComposite is one of the 5 Composite Meta Types defined in Zest.
See the Service Composite chapter.
A side effect is a stateless Fragment, shared between invocations, that acts as an interceptor of the call to the Mixin. The SideEffect is a Java class, that either implements the MixinType it can be used on, or java.lang.reflect.InvocationHandler which allows it to be used on any arbitrary MixinType.
SideEffects are executed after the completion of the method invocation and therefore cannot change parameters nor eventually returned object.
SideEffects have many purposes. Use-cases involves;
SideEffects are established by the use of the @SideEffects annotation on composites.
SideEffect is one of the 3 kinds of Modifiers defined in Zest.
Zest™ promotes a conventional view of application structure, that computer science has been using for decades.
The definition is as follows;
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.
TransientComposite is a Composite Meta Type for all other cases. The main characteristics are;
TODO
This term has no definition yet. Learn how to contribute in Writing Documentation.
Usage of value objects is one of the most ignored and best return-on-investment the programmer can do. Values are immutable and can be compared by value instead of memory reference. Concurrency is suddenly not an issue, since either the value exists or it doesn’t, no need for synchronization. Values are typically very easy to test and very robust to refactoring.
Zest™ defines values as a primary meta type through the ValueComposite, as we think the benefits of values are great. The ValueComposite is very light-weight compared to the Entity Composite, and its value can still be persisted as part of an Entity Composite via a Property.
The characteristics of a ValueComposite compared to other Composite Meta Types are;