aneshas/eventstore

This system is a Go library for implementing event-sourced architectures, providing an embeddable SQL-based event store with support for SQLite and PostgreSQL. It offers a generic aggregate root abstraction to manage state mutations and versioning, alongside a fault-tolerant projection system for building read models. The library integrates with Ambar for production-grade event replication and includes example applications demonstrating account management patterns.

Users can now project event store events to the Ambar data destination. This change introduces the \ambar\ package, which handles parsing Ambar-specific request payloads (including correlation and causation IDs), decoding events, and mapping them to the internal \StoredEvent\ structure. It also provides an \echoambar\ adapter that wraps the projection logic for use with the Echo web framework, automatically returning the correct Ambar response JSON (success, retry, or keep-going) based on projection errors.

ambar · high confidence

A new example command at example/cmd/ambar\_projections demonstrates how to use the Ambar projection system. It sets up an Echo HTTP server on port 8181 with basic authentication, wrapping an Ambar projection handler that listens for account-related events (NewAccountOpened, DepositMade, WithdrawalMade) and prints them to the console.

_example/cmd/ambar\projections · high confidence

The example/account directory now includes a complete account aggregate implementation demonstrating event sourcing patterns. This includes the account entity with deposit and withdrawal operations, domain event definitions (NewAccountOpened, DepositMade, WithdrawalMade), and ID generation utilities using UUIDs. The implementation shows how to apply events and handle them through On\* methods to maintain aggregate state.

example/account · high confidence

The example/cmd/projections directory now includes a main.go file that demonstrates how to use the eventstore library to create and run projections. This example initializes an event store with SQLite, registers two projection handlers (one for console output and one for writing to a JSON file), and runs the projection engine. The console projection prints account opening events, while the JSON file projection buffers events and flushes them to disk every 3 seconds using the FlushAfter helper.

example/cmd/projections · high confidence

The library now provides an embeddable SQL-based event store backed by GORM, supporting both SQLite and PostgreSQL databases. It includes core capabilities for appending and reading events from streams, optimistic concurrency control, and aggregate root abstraction. Additionally, a fault-tolerant projection system is introduced to build read models, featuring real-time event streaming via polling and integration with Ambar.cloud for production workloads.

(repo-wide) · high confidence

The \aggregate\ package introduces a generic event-sourcing foundation for Go, providing a \Root\[T\]\ base type that handles aggregate rehydration, versioning, and event mutation via reflection-based \On{Event}\ handlers. It includes a \Store\[T\]\ to persist and load aggregates from an underlying event store, automatically propagating correlation and causation IDs (with context helpers \CtxWithCorrelationID\ and \CtxWithCausationID\) and metadata. An \Executor\[T\]\ helper simplifies the common pattern of loading an aggregate, executing a mutation function, and saving it back, while tests verify correct behavior for loading, persisting, error handling, and ID propagation.

aggregate · high confidence

The example API now includes a new main entry point that serves HTTP endpoints for creating accounts, depositing funds, and withdrawing funds. By default, it uses an SQLite database, but users can enable Postgres support by passing the -pg flag and setting the DSN environment variable. The API includes middleware for adding request metadata and handles aggregate not found errors with a 404 response.

example/cmd/api · high confidence

The \eventstore\ package has been removed, deleting the SQLite-backed implementation that previously provided stream-based event persistence. This eliminates the \EventStore\ struct and its associated methods (\AppendStream\, \ReadStream\), along with the optimistic concurrency check logic and the stubbed \Projection\ system. Users relying on this specific storage backend must migrate to an alternative event store implementation.

eventstore · high confidence

The example application has been completely rewritten to demonstrate a different event-sourcing pattern. The previous 'Meeting' aggregate example, which relied on the \goddd\ library and a simple in-memory store, has been removed. It is replaced by an 'Account' aggregate example that uses \EventStore\ (with SQLite) and includes HTTP API endpoints for account operations. The new example features three projections: two using built-in projection mechanisms (one with flush support) and one utilizing the Ambar wrapper library for PostgreSQL-based event replication, requiring specific database configuration for the Ambar integration.

example · high confidence

The core library module has been renamed from github.com/aneshas/goddd to github.com/aneshas/eventstore, and the minimum Go version has been raised to 1.23. This update introduces support for PostgreSQL and SQLite via GORM drivers, adds transaction handling through the aneshas/tx/v2 library, and includes test infrastructure using testcontainers-go. The example project has also been updated to reflect these changes, pointing to the new eventstore module.

(dependencies) · high confidence

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

• CAI 61 → 63 (+1.6)
• Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 97 → 97 (+0.1)
• Architecture 100 → 94 (-5.5)
• Maturity 50 → 54 (+3.7)
• Readiness 50 → 54 (+3.9)
• Security 85 → 80 (-5.7)

• Coverage not included — suite not readable by the collector
• Dependency hygiene not measured — no supported dependency manifest was read
• Duplicated block (14 lines × 2) (example/cmd/api/main.go)
• High: security finding (details withheld)
• High: security finding (details withheld)
• No exposed public API
• Small-team knowledge concentration
• Test reliability not included

• Critical CVE: [GHSA redacted] (go.mod)
• Critical CVE: [GHSA redacted] (go.mod)
• Duplicated block (14 lines × 2) (example/cmd/api/main.go)
• High CVE: [GHSA redacted] (go.mod)
• High CVE: [GHSA redacted] (go.mod)
• High CVE: [GHSA redacted] (go.mod)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• Medium CVE: [GHSA redacted] (go.mod)
• Medium CVE: GO-2025-4006 (go.mod)
• Medium CVE: GO-2026-5024 (go.mod)
• Medium CVE: GO-2026-5970 (go.mod)
• Medium vulnerability: GO-2026-5841 (go.mod)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• Medium: security finding (details withheld)
• No dependency advisory monitoring
• Outdated: github.com/labstack/echo/v4
• Outdated: github.com/labstack/echo/v4
• …and 11 more

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

aneshas/eventstore 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.