Skip to content
CAI
Software that uses CAICheck a score

envato/event_sourcery

68.4

Adequate · 22 September 2026

1.9k

lines of production code

Ruby

primary language

7

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

EventSourcery is a Ruby gem that provides a framework for implementing event sourcing patterns. It offers core abstractions for managing aggregate state, persisting events, and processing event streams in isolated child processes. The system includes configurable error handling strategies, multiple event store implementations (including an in-memory variant for testing), and comprehensive tooling for serialization and subscription management.

How it got here

2016 — Rebranding to EventSourcery

14 changes.

The project was renamed from ESFramework to EventSourcery, involving a complete restructuring of the codebase and test suite. This period focused on establishing the new library's core components, such as AggregateRoot and EventStore, while removing the legacy ESFramework code and dependencies.

2017 — In-memory store and error handling

6 changes.

This period focused on expanding the library's capabilities with configurable error handling strategies and an in-memory event store for testing. The work included introducing flexible event type serialization, adding RSpec shared examples for validation, and ensuring comprehensive test coverage for these new components.

Features

Add RSpec shared examples for event store implementations

A new RSpec shared example suite has been added to \lib/event\_sourcery/rspec/event\_store\_shared\_examples.rb\, allowing other projects to easily test their event store implementations against a common set of behaviors. The tests verify that event stores correctly handle auto-incrementing IDs, UUIDs, body serialization, causation and correlation IDs, batch writes, aggregate versioning, and filtering by event type.

_lib/event\sourcery/rspec · high confidence

Add project governance and configuration files

The repository now includes a .gitignore file to exclude build artifacts and environment files, a .rubocop.yml configuration file to enforce Ruby code style and exclude test directories from complexity metrics, and a .rubocop\_todo.yml file to track existing style violations. Additionally, the project has added a Code of Conduct, an MIT LICENSE.txt, and an .rspec configuration file. The Rakefile has been updated to include RuboCop tasks and remove the database task.

(repo-wide) · high confidence

Introduce EventSourcery gem with AggregateRoot, Repository, and Event classes

The EventSourcery gem is introduced, providing core classes for event sourcing. This includes the \AggregateRoot\ module for managing aggregate state and event handling, a \Repository\ class for loading and saving aggregates, and an \Event\ class with support for upcasting and custom event classes. The library also adds configuration for error handling, event type serialization, and event body serialization, along with specific error classes like \EventProcessingError\.

_lib/event\sourcery · high confidence

Introduce configurable event type serializers

The library now supports three strategies for serializing and deserializing event types: ClassName (using the class's full name), Underscored (using an underscored version of the class name), and Legacy (which returns nil for serialization and a generic Event for deserialization). The Underscored serializer includes a built-in inflector that can be replaced with ActiveSupport's inflector via a class variable setter, allowing users to choose how event types are stored in the event store.

_lib/event\_sourcery/event\_store/event\_type\serializers · high confidence

Introduce in-memory event sourcing components for testing and development

Added new in-memory implementations for event sourcing, including a configuration class, an in-memory event store, a projector, and a tracker. These components provide a non-persisted, easy-to-switch alternative to the Postgres-based event store, enabling simpler testing and development workflows. The in-memory store supports event storage, retrieval, and listener-based projection, while the tracker manages processed event IDs in memory.

_lib/event\sourcery/memory · high confidence

Introduces new event store components for subscriptions and polling

The event store module now includes dedicated classes for managing subscriptions and polling: SignalHandlingSubscriptionMaster handles graceful shutdowns via OS signals, while PollWaiter manages the polling loop. A new Subscription class allows Event Stream Processors to listen for new events, with support for filtering by event type and configurable batch sizes. Additionally, EventBuilder constructs event objects from serialized data, and EventSource/EventSink delegate retrieval and storage operations. The legacy ESFramework::EventSource was refactored into EventStore::EachByRange, adding support for filtering by event type during iteration.

_lib/event\_sourcery/event\store · high confidence

New error handling strategies for event processors

Added three new error handling strategies for event processors: ConstantRetry, which retries indefinitely with a fixed interval; ExponentialBackoffRetry, which retries with exponentially increasing delays; and NoRetry, which terminates the process on error. These new classes implement the ErrorHandler interface, providing users with configurable ways to manage processor failures.

_lib/event\_sourcery/event\_processing/error\handlers · high confidence

Removals

Removal of the ESFramework event-sourcing library

The entire ESFramework library has been removed from the codebase. This includes all core components such as the EventProcessor, Projector, and Command modules, as well as all associated adapters for event sources, sinks, and subscribers (including memory and Postgres implementations). Users relying on this framework for event sourcing capabilities will need to migrate to an alternative solution.

_lib/es\framework · high confidence

Behavioural changes

Introduce dedicated processes and registry for event stream processors

The event stream processing architecture has been refactored to support running processors in separate child processes for better isolation and fault tolerance. A new \ESPProcess\ class manages the lifecycle of a single processor in its own process, while \ESPRunner\ orchestrates multiple processors, handling signal trapping, graceful shutdown, and process monitoring. The \EventStreamProcessor\ module now registers each processor class with a new \EventStreamProcessorRegistry\, which allows for easy discovery and filtering of processors by name or event type. This change introduces a more robust, process-based execution model for event handling.

_lib/event\_sourcery/event\processing · high confidence

Rename library to EventSourcery and restructure the codebase

The library has been renamed from ESFramework to EventSourcery, with all internal namespaces and file paths updated to reflect this change. The codebase has been restructured to organize event sourcing components into distinct modules: event store, event processing, and memory implementations. This includes moving event store and tracker code into the EventSourcery::EventStore and EventSourcery::Memory namespaces, while event processing logic is now under EventSourcery::EventProcessing. The main entry point now provides a configure block for setting up the framework, including error handling, logging, and event body serialization. The old ESFramework module and its associated files have been removed.

lib · high confidence

Updated console and setup scripts for EventSourcery

The bin/console script now requires 'event\_sourcery' and automatically starts Pry for interactive debugging, replacing the previous IRB-based console. The bin/setup script was updated to include bundling and automatically create the 'event\_sourcery\_test' database if it does not already exist.

bin · high confidence

Test coverage

Added comprehensive test coverage for EventSourcery core components; Added comprehensive test coverage for event processing components; Added test coverage for EventSourcery event store components; Added test coverage for event processing error handlers; Added tests for the in-memory event store components; Refactor test support files and add event definitions; Removed ESFramework test suite; Updated RSpec configuration and test suite structure.

Dependencies

Migrate gemspec and dependencies to EventSourcery

The project's gemspec has been updated to reflect the new 'EventSourcery' name and authorship, with a required Ruby version of 2.6 or higher. The dependency list has been cleaned up: 'logger' is now a runtime dependency, while 'rollbar' and 'virtus' have been removed. Development dependencies now pin 'rake' to version 13 and 'rubocop' to version 1, and the 'es\_framework' gemspec has been removed in favor of the new structure.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

How this codebase got here

This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.

Score

  • CAI 67 → 68 (+1.1)
  • Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

Lenses

  • Code Health 100 → 100 (+0.0)
  • Architecture 100 → 95 (-4.9)
  • Maturity 54 → 54 (+0.0)
  • Readiness 58 → 65 (+7.1)
  • Security 100 → 100 (+0.0)

Resolved (6)

  • Coverage not included — suite not readable by the collector
  • Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
  • No exposed public API
  • Off-boarding risk: anonymized user #1
  • Test reliability not included
  • The Getting Started section recommends watching an in-depth YouTube video but does not provide a link to it. (README.md)

New (10)

  • Duplicate method name serialize with different signatures. One takes an explicit serializer argument, the other does not. This creates ambiguity for callers and potential confusion in documentation.
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • Inconsistent naming for configuration accessors. The top-level module and the Memory submodule both expose configure (setter) and config (getter). However, EventSourcery also exposes EventSourcery.config() which returns a Config object, while EventSourcery.configure() is likely a setter. This pattern is duplicated in Memory. While consistent within each module, the presence of both configure and config on the same object can be ambiguous regarding whether config is a getter or a configuration DSL method. More critically, EventSourcery.Config has a method logger() which duplicates the property logger defined in the same class.
  • Inconsistent naming for error handling strategy application. The base interface ErrorHandler and all concrete implementations (ConstantRetry, ExponentialBackoffRetry, NoRetry) use with_error_handling. However, this method name is generic and doesn't clearly indicate it returns a wrapper or modifies behavior. If this is a decorator pattern, wrap or decorate might be clearer, but the main inconsistency is that EventProcessingError is a distinct type from the handlers, yet the handlers all share this specific method name which might be confused with a callback registration if not documented well. More importantly, EventSourcery.EventProcessing.ErrorHandlers is an empty namespace/module, while EventSourcery.EventProcessing.ErrorHandlers.ErrorHandler is the base class. This is a structural inconsistency in how the hierarchy is exposed.
  • No dependency advisory monitoring
  • Off-boarding risk: anonymized user #1
  • Workflow token permissions not restricted

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Survey your own repository

envato/event_sourcery was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.

About this page

  • The score is its most recent published measurement, taken on 22 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 61a82fd5a24d07642946b1a3b67b876db676aac6 — the exact code this score is about.
  • Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-821afab8930d.