Context Handler

This page is stale and no longer accurately reflects context handlers. Please refer to the handler concept for further clarity.

Note that an Entity can define a handler too, but they are different than the handlers defined in a context. See Entity Handler for more details.

There are two kinds of handlers as described in the following sections. They are differentiated by the existence of a for clause in their definition. If they have for clause, then they are [Projection Handlers](#Projection Handler) ; otherwise they are [API Handlers](#API Handler)

A handler that has a for projection <path> clause specifies how events should update a projection’s data set. There can only be one handler per projection defined in the context. The handler definition for a projection must be defined in the same context as the projection.

When a handler definition does not have a for projection <path> clause, it specifies how to handle the messages sent to the context; in other words it allows a context to represent an arbitrary stateless application programming interface(API). This permits higher level functional gateways to summarize the behavior of entire subdomains and bounded contexts.

APIs are always stateless. Any state that needs to be saved when an API function is invoked should be done by sending commands to a persistent entity from an on clause in the handler.

A context can define multiple API handlers. The will simply be combined to form the full API. This allows for modula definition of the API.