engine v0.1.2 API Reference

Modules

This module encapsulates the Database side-efects over the aggregate Container. So the data structure from server state (that contains the aggregate data structure) and rehydrate it with data, from snapshots and events. Easier to test, debug and mantain :) . So we focus only on retrieving and persisting data here, creating new pids, and other decisions should be make by the server, repository and router

Container for aggregates, Allows execution of commands against an aggregate and handles persistence of events to the event store. https://pdincau.wordpress.com/2013/04/17/how-to-handle-configuration-in-init1-function-without-slowing-down-your-erlang-supervisor-startup/

The Bus receives commands and events from the API and publish them, so the handlers may take care of the commands and events to apply them to the suitable aggregates. TODO: use eventstore eventbus with extreme, see: https://github.com/exponentially/extreme

Eventstore database use PROTOBUF, that is a compressed binary protocol. So all our communication with Eventstore is through messaging. Here we create this messages to send afterwards them to Hey, only! the store.ex is using this API. This is the most ‘low level’ communication with the ES Eventstore. Example: events = [%PersonCreated{name: “Pera Peric”}, %PersonChangedName{name: “Zika”}] Common.Factory.write_events(“people”, events) Note that it will first create_event for every event in the list of events

This module is the Repository for Aggregates, Process Managers, or anything else that has a PID and you want to store and load the state from cache, from some snapshot, replay events from that snapshot or even from the begining. For several reasons we choosed SYN to store pids. Note that the BPE https://github.com/spawnproc/bpe also choosed SYN. http://www.ostinelli.net/an-evaluation-of-erlang-global-process-registries-meet-syn/ https://github.com/ostinelli/syn

It gives the configuration value based on key, but if the configuration was not specified in the config.exs file, the default configuration will be used

Interface with the Extreme EventStore driver to save and read to EVENTSTORE. Note that the Engine supervisor starts the driver naming it as ‘EventStore’. iex> Engine.EventStore.save_event(“people”,%Obligation.Event.MoneyDeposited{}) This Eventstore interface is intelligent when saving snapshots

Interface with the Postgre eventstore lib, driver to save and read to POSTGRE

Map raw events to event data structs ready to be persisted to the event store

It’s possible that you want to serialize all your messages to json before sending to the EventStore, or you can choose to save as a binary, or hybrid, like, your event data in binary and the whole Eventstore message in json. To define your event data, go to Engine.Messages, and to serialize the whole message see the Engine.EventStore

Proxy API layer to provide a Facade for different data storages. The ideia is to read from the config file what is the choosen storage, and route the call to the specifc implementation. http://elixir-lang.org/docs/stable/elixir/typespecs