Event Driven Architecture

Event Driven Architecture

General Behavior

The event driven architecture is simple at its core.

1. Event names are registered in the Event class
2. Behavior records are added to the database with event_names that correspond to those registered events
3. An Event is triggered in Aperta, maybe in response to something like an AASM state change, with a specific event name.
4. The Event class queries the DB for any Behaviors with an event_name that matches that triggered name, and invokes them
5. Behaviors all implement a call method to run specific behavior.

AASM Transitions

On top of the general behavior, Aperta implements more specific functionality. Any class including the AASMTriggerEvent can call register_events! to register events for all of its AASM transitions. The Paper class does this, registering the following events:

paper.state_changed.unsubmitted paper.state_changed.initially_submitted paper.state_changed.invited_for_full_submission paper.state_changed.submitted paper.state_changed.checking paper.state_changed.in_revision paper.state_changed.accepted paper.state_changed.rejected paper.state_changed.published paper.state_changed.withdrawn

In an after_transition hook, the paper will create a new StateChangeEvent and trigger it. StateChangeEvent is a subclass of Event that creates a proper event name from an AASM state. The sequence diagram below shows how the system can send an email based on a paper state change. SendEmailBehavior is a Behavior subclass that will send an email with a specified letter template.