`stopping-definition` to stop when causality is broken.

Causality is a property of the simulation model stating that a future event cannot change what has been done in the past already, so all changes in the state should not contradict any past event.

In practise, we check the `next-snapshot` `date` is equal or after the current `snapshot`.

`stopping-definition` to stop when the execution of an event is not found in the registry.

`stopping-definition` to stop when an execution has raised an exception.

`stopping-definition` to stop when no future events exists anymore.

built-in `stopping-definition` can create `stopping-cause` but they are not accessible for modellers, they are hard coded.

Stops when the request is not valid.

Stops when the response is not valid.

Registry for middlewares associating a keyword to its middleware function.

Stops when the request is valid through inconsistency and schema.
This criteria is built-in to this middleware as it is requiring the `request` knowledge. User `stopping-criteria` knows only `snapshot`.

Stops when the response is valid through inconsistency and schema.
This criteria is built-in to this middleware as it is requiring the `response` knowledge. User `stopping-criteria` knows only `snapshot`.

Middleware to render state.

Middleware to tap response and requests.

Ordered list of middlewares.

* [See entity](docs/archi/middlewares_entity.png)

A simulation model gathers information required to run the simulation.

It includes:

* `initial-snpashot` snapshot to start the model with.
* `middlewares` sequence of middleware to execute with the model.
* `model-data` data version of this model.
* `ordering` ordering of events.
* `registry` registry.
* `stopping-criterias` list of `stopping-criteria` that defines the end of the model.

Model data is the data used as inputs to generate the model:

* data oriented, so it could be persisted easily.
* ergonomy oriented, so it is easy to use.

Registry for ordering.

Gathers the registries of a simulation.

The `scheduler` is working with a `model` describing the problem to solve.

For each scheduler snapshot created, the scheduler is sorting the `future-events` based on the event ordering defined in the event-registry. The first event of that order is executed (see event execution). The resulting new values of state, past events, future events are used to create the new scheduler snapshot.

An event has three parameters `(event-execution current-event state new-future-events)`:
* `current-event` which is the current event to execute
* `state` which is the state value before the event execution
* `new-future-events` which is the list of future events without the current event

The returned value is a `event-return`, which future events have no needs to be sorted, they will be by the scheduler.

![entities](archi/scheduler_entity.png)
![aggregate](archi/scheduler_aggregate.png)
![state diagram](archi/scheduler_state.png)

`stopping-definition` to stop at a given bucket.

`stopping-definition` to stop at a given iteration.

`stopping-definition` to stop right now.

Stopping registry contains all `stopping-definition`.

![Entities](archi/simulation_engine/stopping_registry.png)

A reason why the `scheduler` stops. A `stopping-cause` contains:

* `context` data describing the context of the `stopping-criteria`, note its schema is defined freely by each `stopping-definition`.
* `current-event` the event that is about to be executed now. It could be null, if future-event is nil and no first event found.
* `stopping-criteria` telling the intent of the user to stop.

![Entities](archi/simulation_engine/stopping_cause.png)

Declares a `stopping-criteria` to instantiate `stopping-definition`s, it precises the `params` necessary for `stopping-evaluation`.
The data are:

* `model-end?` is set to `true` if the stopping-criteria is one possible end of the model. Note that more than one is possible for the same model. Note that these model `stopping-criteria` are not supposed to be linked with anything else than the business model itself (not the rendering, not the control/computation, ...)
* `params` is a map of parameters, which content is defined by the `stopping-definition`.
* `stopping-definition` is the `stopping-definition` as found in the `stopping-registry`.

![entities][archi/simulation_engine/stopping_stopping-criteria.png]

A `stopping-definition` defines what could cause the scheduler to stop.

* `doc` describes the definition.
* `id` name of the `stopping-definition`
* `next-possible?` tells if the next call of the `scheduler` will raise the same error.
* `stopping-evaluation` is the function to be called to evalute the criteria and decides if stops is true or not.

Note that only `stopping-definition` with `stopping-evaluation` properly set are callable by users. Others are built-in `stopping-definition` triggering `stopping-cause` in the `simulation-engine` bounded context.

![Entities](archi/simulation_engine/stopping_definition.png)