event_sourcery 0.13.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 5a53861c6b78ba25db797887cbb523bec700832a
+  data.tar.gz: 2cc44cb2db162bf4b1f35e356e24eab1c213534d
+SHA512:
+  metadata.gz: 77e1852829109a6fcab8e4c2efb930de89b88dfa45eccbecf761484c7a19f6ab8825fd9179c9112002e6c82ab281033106dc0da60fad2f8be76dd97e0c42d782
+  data.tar.gz: e0c6879eb49868144c628b6649c37d6577637f3514ef2653606a47d342cd820c9ed38f44588f77acd145f7b528a98b314a3c9189e27cd8f2971391c9ffe2978c

data/.gitignore

@@ -0,0 +1,37 @@
+# Created by .ignore support plugin (hsz.mobi)
+### Ruby template
+*.gem
+*.rbc
+/.config
+/coverage/
+/InstalledFiles
+/pkg/
+/spec/reports/
+/spec/examples.txt
+/test/tmp/
+/test/version_tmp/
+/tmp/
+
+# Used by dotenv library to load environment variables.
+# .env
+
+## Documentation cache and generated files:
+/.yardoc/
+/_yardoc/
+/doc/
+/rdoc/
+
+## Environment normalization:
+/.bundle/
+/vendor/bundle
+/lib/bundler/man/
+
+# for a library or gem, you might want to ignore these files since the code is
+# intended to run in multiple environments; otherwise, check them in:
+Gemfile.lock
+.ruby-version
+.ruby-gemset
+
+# unless supporting rvm < 1.11.0 or doing something fancy, ignore this:
+.rvmrc
+

data/.rspec

@@ -0,0 +1,3 @@
+--require spec_helper
+--format documentation
+--color

data/.travis.yml

@@ -0,0 +1,8 @@
+sudo: false
+language: ruby
+rvm:
+  - 2.2
+  - 2.3
+  - 2.4
+before_install:
+  - gem install bundler

data/CHANGELOG.md

@@ -0,0 +1,82 @@
+# Change Log
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](http://keepachangelog.com/)
+and this project adheres to [Semantic Versioning](http://semver.org/).
+
+## [Unreleased]
+### Added
+- The core Event class accepts `causation_id` to allow event stores to
+  add support for tracking causation ids with events.
+- The core Memory event store saves the `causation_id` and `correlation_id`.
+
+### Changed
+- The event store shared RSpec examples specify event stores should save
+  the `causation_id` and `correlation_id`.
+
+### Removed
+- The `processing_event` method from the memory tracker. It was intended to
+  be a mechanism to wrap processing and tracker updates which appears to be
+  universally unused at this point.
+
+## [0.12.0] - 2017-6-1
+### Removed
+- Removed usage `#shutdown!` as it should be a private method within custom PollWaiters.
+  An example of how event_sourcery-postgres has implemented `#shutdown!` can be
+  found [here](https://github.com/envato/event_sourcery-postgres/pull/5)
+
+## [0.11.2] - 2017-5-29
+### Fixed
+- Fixed: default poll waiter now implements `shutdown!`
+
+## [0.11.0] - 2017-5-29
+### Fixed
+- Use `processor.class.name` to set ESP process name
+- Convert `processor_name` symbol to string explicitly
+
+## [0.11.0] - 2017-5-26
+### Added
+- Make Event processing error handler class Configurable
+- Add exponential back off retry error handler
+
+## [0.10.0] - 2017-5-24
+### Added
+- The core Event class accepts `correlation_id` to allow event stores to
+  add support for tracking correlation IDs with events.
+- `Repository#save` for saving aggregate instances.
+- Configuration option to define custom event body serializers.
+
+### Fixed
+- Resolved Sequel deprecation notice when loading events from the Postgres event
+  store.
+
+### Changed
+- Aggregates no longer save events directly to an event sink. They must be
+  passed back to the repository for saving with `repository.save(aggregate)`.
+- `AggregateRoot#apply_event` signature has changed from accepting an event or
+  a hash to accepting an event class followed by what would normally go in the
+  constructor of the event.
+
+### Removed
+- Postgres specific code has moved to the [event_sourcery-postgres](https://github.com/envato/event_sourcery-postgres) gem.
+  Config options for postgres have moved to `EventSourcery::Postgres.config`.
+
+## [0.9.0] - 2017-05-02
+### Added
+- Add `table_prefix` method to `TableOwner` to declare a table name prefix for
+  all tables in a projector or reactor.
+
+### Changed
+- Schema change: the `writeEvents` function has been refactored slightly.
+- The `Event` class no longer uses `Virtus.value_object`.
+- `AggregateRoot` and `Repository` are namespaced under `EventSourcery` instead
+  of `EventSourcery::Command`.
+- `EventSourcery::Postgres` namespace has been extracted from
+  `EventSourcery::(EventStore|EventProcessing)::Postgres` in preparation for
+moving all Postgres related code into a separate gem.
+- An advisory lock has replaced the exclusive table lock used to synchronise
+  event inserts.
+
+### Removed
+- EventSourcery no longer depends on Virtus.
+- `Command` and `CommandHandler` have been removed.

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,74 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers pledge to making participation in our project and
+our community a harassment-free experience for everyone, regardless of age, body
+size, disability, ethnicity, gender identity and expression, level of experience,
+nationality, personal appearance, race, religion, or sexual identity and
+orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+  address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting the project team at odindutton@gmail.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project team is
+obligated to maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/

data/Gemfile

@@ -0,0 +1,5 @@
+source 'https://rubygems.org'
+
+ruby '>= 2.2.0'
+
+gemspec

data/LICENSE.txt

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2017 Envato
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/README.md

@@ -0,0 +1,399 @@
+# EventSourcery
+
+[![Build Status](https://travis-ci.org/envato/event_sourcery.svg?branch=master)](https://travis-ci.org/envato/event_sourcery)
+
+A framework for building event sourced, CQRS applications.
+
+**Table of Contents**
+
+- [Development Status](#development-status)
+- [Goals](#goals)
+- [Getting Started Guide](#getting-started-guide)
+- [Configuration](#configuration)
+- [Development](#development)
+    - [Dependencies](#dependencies)
+    - [Running the Test Suite](#running-the-test-suite)
+    - [Release](#release)
+- [Core Concepts](#core-concepts)
+    - [Tour of an EventSourcery Web Application](#tour-of-an-eventsourcery-web-application)
+    - [Events](#events)
+    - [The Event Store](#the-event-store)
+        - [Storing Events](#storing-events)
+        - [Reading Events](#reading-events)
+    - [Aggregates and Command Handling](#aggregates-and-command-handling)
+    - [Event Processing](#event-processing)
+        - [Event Stream Processors](#event-stream-processors)
+        - [Projectors](#projectors)
+        - [Reactors](#reactors)
+        - [Running Multiple ESPs](#running-multiple-esps)
+    - [Typical Flow of State in an Event Sourcery Application](#typical-flow-of-state-in-an-event-sourcery-application)
+        - [1. Handling a Command](#1-handling-a-command)
+        - [2. Updating a Projection](#2-updating-a-projection)
+        - [3. Handling a Query](#3-handling-a-query)
+
+## Development Status
+
+EventSourcery is currently being used in production by multiple apps but we
+haven't finalized the API yet and things are still moving rapidly. Until we
+release a 1.0 things may change without first being deprecated.
+
+## Goals
+
+The goal of EventSourcery is to make it easier to build event sourced, CQRS applications.
+
+The hope is that by using EventSourcery you can focus on modeling your domain with aggregates, commands, and events; and not worry about stitching together application plumbing.
+
+## Getting Started Guide
+
+EventSourcery currently supports a Postgres-based event store via the [event_sourcery-postgres](https://github.com/envato/event_sourcery-postgres) gem.
+
+**TODO**
+
+## Configuration
+
+There are several ways to configure Event Sourcery to your liking. The following presents some examples:
+
+```ruby
+EventSourcery.configure do |config|
+  # Add custom reporting of errors occurring during event processing.
+  # One might set up Rollbar here.
+  config.on_event_processor_error = proc { |exception, processor_name| … }
+
+  # Enable Event Sourcery logging.
+  config.logger = Logger.new('logs/my_event_sourcery_app.log')
+
+  # Customize how event body attributes are serialized
+  config.event_body_serializer
+    .add(BigDecimal) { |decimal| decimal.to_s('F') }
+
+  # Config how your want to handle event processing errors
+  config.error_handler_class = EventSourcery::EventProcessing::ErrorHandlers::ExponentialBackoffRetry
+end
+```
+
+## Development
+
+### Dependencies
+
+- Ruby
+
+### Running the Test Suite
+
+Run the `setup` script, inside the project directory to install the gem dependencies and create the test database (if it is not already created).
+```bash
+./bin/setup
+```
+
+Then you can run the test suite with rspec:
+```bash
+bundle exec rspec
+```
+
+### Release
+
+To release a new version:
+
+1. Update the version number in `lib/event_sourcery/version.rb`
+2. Get this change onto master via the normal PR process
+3. Run `bundle exec rake release`, this will create a git tag for the
+   version, push tags up to GitHub, and package the code in a `.gem` file.
+
+## Core Concepts
+
+Not sure what Event Sourcing (ES), Command Query Responsibility Segregation (CQRS), or even Domain-Driven Design (DDD) are? Here are a few links to get you started:
+
+- [CQRS and Event Sourcing Talk](https://www.youtube.com/watch?v=JHGkaShoyNs) - by Greg Young at Code on the Beach 2014
+- [DDD/CQRS Google Group](https://groups.google.com/forum/#!forum/dddcqrs) - from people new to the concepts to old hands
+- [DDD Weekly Newsletter](https://buildplease.com/pages/dddweekly/) - a weekly digest of what's happening in the community
+- [Domain-Driven Design](https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215) - the definitive guide
+- [Greg Young's Blog](https://goodenoughsoftware.net) - a (the?) lead proponent of all things Event Sourcing
+
+### Tour of an EventSourcery Web Application
+
+Below is a high level view of a CQRS, event-sourced web application built using EventSourcery. The components marked with `*` can be created using building blocks provided by EventSourcery. Keep on reading and we'll describe each of the concepts illustrated.
+
+```
+   ┌─────────────┐                        ┌─────────────┐
+   │             │                        │             │
+   │   Client    │                        │   Client    │
+   │             │                        │             │
+   └─────────────┘                        └─────────────┘
+          │                                      │
+    Issue Command                           Issue Query
+          │                                      │
+  ┌───────┴──────────────────────────────────────┴─────────┐
+  │                       Web Layer                        │
+  └───────┬──────────────────────────────────────┬─────────┘
+          │                                      │
+          ▼                                      ▼
+   ┌─────────────┐                        ┌─────────────┐
+   │   Command   │                        │Query Handler│
+   │   Handler   │                        │             │
+   └─────────────┘                        └─────────────┘
+          │                                      │
+          ▼                              ┌───────▼─────┐
+   ┌─────────────┐                       │┌────────────┴┐
+   │ * Aggregate │                       ││* Projection │
+   │             │                       └┤             │
+   └─────────────┘                        └─────────────┘
+          │                                      ▲
+          │                                      │
+          │                              Update Projection
+          │                                      │
+     Emit Event                           ┌─────────────┐
+          │                               │┌────────────┴┐
+          │                               ││ * Projector │
+          ▼                               └┤             │
+   ┌─────────────┐                         └─────────────┘
+   │* Event Store│       Process                  ▲
+┌─▶│             │────────Event───────────────────┘
+│  └─────────────┘
+│         │
+│      Process     ┌─────────────┐
+│       Event      │┌────────────┴┐               ┌ ─ ─ ─ ─ ─ ─ ┐
+│         └───────▶││  * Reactor  │                  External
+│                  └┤             │───Trigger ───▶│   System    │
+│                   └─────────────┘  Behaviour     ─ ─ ─ ─ ─ ─ ─
+│                          │
+│                          │
+└────────Emit Event────────┘
+
+```
+
+### Events
+
+Events are value objects that record something of meaning in the domain. Think of a sequence of events as a time series of immutable domain facts.
+
+Events are targeted at an aggregate via an `aggregate_id` and have the following attributes.
+
+```ruby
+module EventSourcery
+  class Event
+    attr_reader \
+      :id,             # Sequence number
+      :uuid,           # Unique ID
+      :aggregate_id,   # ID of aggregate the event pertains to
+      :type,           # type of the event
+      :body,           # the payload (a hash)
+      :version,        # Version of the aggregate
+      :created_at,     # Created at date
+      :correlation_id  # Correlation ID for tracing purposes
+
+    # ...
+  end
+end
+```
+
+You can define events in your domain as follows.
+
+```ruby
+TodoAdded = Class.new(EventSourcery::Event)
+
+# An example instance.
+# #<TodoAdded:0x007fb6f88f04b0
+#   @id=24,
+#   @uuid="75dcc7eb-33c0-4f1c-ac23-31bf32fc5edc",
+#   @aggregate_id="fca315ff-d45d-46c5-a230-67c5bec0b06d",
+#   @type="todo_added",
+#   @body={"title"=>"My task"},
+#   @version=1,
+#   @created_at=2017-06-14 11:50:32 UTC,
+#   @correlation_id="b4d1e31d-9d1b-4ea1-a685-57936ce65a80">
+```
+
+### The Event Store
+
+The event store is a persistent store of events.
+
+EventSourcery currently supports a Postgres-based event store via the [event_sourcery-postgres gem](https://github.com/envato/event_sourcery-postgres).
+
+For more information about the `EventStore` API refer to [the postgres event store](https://github.com/envato/event_sourcery-postgres/blob/master/lib/event_sourcery/postgres/event_store.rb) or the [in memory event store in this repo](lib/event_sourcery/event_store/memory.rb)
+
+#### Storing Events
+
+Naturally, it provides the ability to store events. The event store is append-only and immutable. The events in the store form a time-ordered sequence which can be viewed as a stream of events.
+
+`EventStore` clients can optionally provide an expected version of event when saving to the store. This provides a mechanism for `EventStore` clients to effectively serialise the processing they perform against an instance of an aggregate.
+
+When used in this fashion the event store can be thought of as an event sink.
+
+#### Reading Events
+
+The `EventStore` also allows clients to read events. Clients can poll the store for events of specific types after a specific event ID. They can also subscribe to the event store to be notified when new events are added to the event store that match the above criteria.
+
+When used in this fashion the event store can be thought of as an event source.
+
+### Aggregates and Command Handling
+
+> An aggregate is a cluster of domain objects that can be treated as a single unit. Every transaction is scoped to a single aggregate. An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole.
+>
+> <cite>— [DDD Aggregate](http://martinfowler.com/bliki/DDD_Aggregate.html)</cite>
+
+Clients execute domain transactions against the system by issuing commands against aggregate roots. The result of these commands is new events being saved to the event store.
+
+A typical EventSourcery application will have one or more aggregate roots with multiple commands.
+
+### Event Processing
+
+A central part of EventSourcery is the processing of events in the store. Event Sourcery provides the Event Stream Processor abstraction to support this.
+
+```
+                                           ┌─────────────┐          Subscribe to the event store
+                                           │Event Stream │          and take some action. Tracks
+                                           │  Processor  │◀─ ─ ─ ─ ─its position in the stream in
+                                           │             │           a way that suits its needs.
+                                           └─────────────┘
+                                                  ▲
+                                         ┌────────┴───────────┐
+                                         │                    │
+                                         │                    │
+                                  ┌─────────────┐      ┌─────────────┐
+Listens for events and takes      │             │      │             │        Listens for events and
+   action. Actions include      ─▶│   Reactor   │      │  Projector  │◀─ ┐     projects data into a
+emitting new events into the ─ ┘  │             │      │             │    ─ ─       projection.
+store and/or triggering side      └─────────────┘      └─────────────┘
+    effects in the world.
+```
+
+A typical Event Sourcery application will have multiple projectors and reactors running as background processes.
+
+#### Event Stream Processors
+
+Event Stream Processors (ESPs) subscribe to an event store. They read events from the event store and take some action.
+
+When newly created, an ESP will process the event stream from the beginning. When catching up like this an ESP can process events in batches (currently set to 1,000 events). This allows them to optimise processing as desired.
+
+ESPs track the position in the event stream that they've processed in a way that suits them. This allows for them to optimise transaction handling in the case where they are catching up for example.
+
+#### Projectors
+
+A Projector is an EventStreamProcessor that listens for events and projects data into a projection. These projections are generally consumed on the read side of the CQRS world.
+
+Projectors tend to be built for specific read-side needs and are generally specific to a single read case.
+
+Modifying a projection is achieved by creating a new projector.
+
+#### Reactors
+
+A Reactor is an EventStreamProcessor that listens to events and emits events back into the store and/or trigger side effects in the world.
+
+They typically record any external side effects they've triggered as events in the store.
+
+#### Running Multiple ESPs
+
+An EventSourcery application will typically have multiple ESPs running. EventSourcery provides a class called [ESPRunner](lib/event_sourcery/event_processing/esp_runner.rb) which can be used to run ESPs. It runs each ESP in a forked child process so each ESP can process the event store independently. You can find an example in [event_sourcery_todo_app](https://github.com/envato/event_sourcery_todo_app/blob/master/Rakefile).
+
+Note that you may instead choose to run each ESP in their own process directly. The coordination of this is not currently provided by EventSourcery.
+
+### Typical Flow of State in an Event Sourcery Application
+
+Below we see the typical flow of state in an Event Sourcery application (arrows indicate data flow). Note that steps 1 and 2 are not synchronous. This means Event Sourcery applications need to embrace [eventual consistency](https://en.wikipedia.org/wiki/Eventual_consistency).
+
+```
+
+       1. Issue Command   │      2. Update Projection     │        3. Issue Query
+
+                          │                               │
+               │                                                          ▲
+               │          │                               │               │
+               │                                                          │
+               │          │                               │          F. Handle
+           B. Handle                                                   Query
+            Command       │                               │               │
+               │                                                          │
+               │          │                               │               │
+               ▼                       ┌─────────────┐                    │
+        ┌─────────────┐   │            │             │    │        ┌─────────────┐
+        │             │       ┌───────▶│  Projector  │             │             │
+     ┌─▶│  Aggregate  │   │   │        │             │    │        │Query Handler│
+     │  │             │       │        └─────────────┘             │             │
+     │  └─────────────┘   │  D. Read          │           │        └─────────────┘
+     │         │              event      E. Update                        ▲
+ A. Load   C. Emit        │   │          Projection       │               │
+state from  Event             │               │                       G. Read
+  events       │          │   │               │           │          Projection
+     │         ▼              │               ▼                           │
+     │  ┌─────────────┐   │   │        ┌─────────────┐    │               │
+     │  │             │       │        │             │                    │
+     └──│ Event Store │───┼───┘        │ Projection  │────┼───────────────┘
+        │             │                │             │
+        └─────────────┘   │            └─────────────┘    │
+
+                          │                               │
+
+```
+
+#### 1. Handling a Command
+
+A command comes into the application and is routed to a command handler. The command handler initialises an aggregate and loads up its state from events in the store. The command handler then defers to the aggregate to handle the command. It then stores any new events raised by the aggregate into the event store.
+
+```ruby
+class AddTodoCommandHandler
+  def handle(id:, title:, description:)
+    # The repository provides access to the event store for saving and loading aggregates
+    repository = EventSourcery::Repository.new(
+      event_source: EventSourcery.config.event_source,
+      event_sink: EventSourcery.config.event_sink,
+    )
+
+    # Load up the aggregate from events in the store
+    aggregate = repository.load(TodoAggregate, id)
+
+    # Defer to the aggregate to execute the add command.
+    # This may raise new events in the aggregate which we'll need to save.
+    aggregate.add(title, description)
+
+    # Save any newly raised events back into the event store
+    repository.save(aggregate)
+  end
+end
+```
+
+#### 2. Updating a Projection
+
+Projecting is process of converting (or collecting) a stream of events into a structural representation. You can think of the process as a fold over a sequence of events. You can think of a projection as a read model that is generally persisted somewhere like a database table.
+
+A projector is a process that listens for new events in the event store. When it sees a new event it cares about it updates its projection.
+
+```ruby
+class OutstandingTodosProjector
+  include EventSourcery::Postgres::Projector
+
+  projector_name :outstanding_todos
+
+  # Define our database table projection
+  table :outstanding_todos do
+    column :todo_id, 'UUID NOT NULL'
+    column :title, :text
+    column :description, :text
+  end
+
+  # Handle TodoAdded events by adding the todo to our projection
+  project TodoAdded do |event|
+    table.insert(
+      todo_id: event.aggregate_id,
+      title: event.body['title'],
+      description: event.body['description'],
+    )
+  end
+
+  # Handle TodoCompleted events by removing the todo from our projection
+  project TodoCompleted, TodoAbandoned do |event|
+    table.where(todo_id: event.aggregate_id).delete
+  end
+end
+```
+
+#### 3. Handling a Query
+
+A query comes into the application and is routed to a query handler. The query handler queries the projection directly and returns the result.
+
+```ruby
+module OutstandingTodos
+  class QueryHandler
+    def handle
+      EventSourceryTodoApp.projections_database[:outstanding_todos].all
+    end
+  end
+end
+```