Pdo Event Sourcing Laravel Package

Product Decisions This Supports

• Event sourcing vs. CRUD, decided incrementally. The package's core promise is architectural optionality: the same codebase can start with #[CommandHandler] CRUD-style handlers and later enable event-sourced aggregates without a rewrite. That reduces the cost of deferring the event-sourcing decision, which is usually the right call until you actually need auditability, replay, or temporal queries.
• Storage backend: relational-first vs. dedicated event store. Because the store is PDO-backed on PostgreSQL/MySQL, this is the "no new infrastructure" option. It lets you answer "do we need to operate EventStoreDB/Kafka just to try event sourcing?" with no, which is a meaningful platform and on-call cost avoidance. The trade-off to weigh is throughput, global ordering guarantees, and operational maturity versus a purpose-built event store.
• Durable workflow orchestration (sagas). Event-sourced sagas mean long-running business processes (order fulfillment, onboarding, payment reconciliation) survive process restarts and can be replayed. This is a real alternative to building a bespoke state machine plus a jobs table, and it feeds directly into whether you buy a workflow engine or build one.
• Read-model and projection strategy. Projections, replay, and upcasting are bundled, which supports decisions about how you serve queries (denormalized read models), how you rebuild them after bug fixes, and how much of your reporting layer you can move off the write model.
• Schema evolution policy. Upcasting is the mechanism that lets you change event shapes without rewriting history. Its presence is a check on "can we evolve our domain model for 3+ years without a painful migration project?"
• Streaming/outbox integration. Streaming projections to Kafka/RabbitMQ let event sourcing double as the integration backbone, which can collapse two roadmap items (internal audit log + external event publishing) into one design.
• Build vs. buy for event-sourcing plumbing. This is squarely in the "buy/borrow the plumbing, build the domain" bucket: aggregates, repository, upcasting, and projections are commodity code you should not hand-roll.

When to Consider This Package

Consider it when:

• You are already on, or deliberately adopting, the Ecotone framework. This is a split sub-package of ecotone/ecotone; it is not a standalone library, and its value is inseparable from that ecosystem.
• Your team is on PHP 8 with an existing PostgreSQL or MySQL footprint and does not want to onboard a new datastore or streaming platform for a first event-sourcing initiative.
• You want an incremental migration path — audit trail or durable sagas first, full event-sourced aggregates later — rather than a flag-day architecture change.
• You need schema evolution (upcasting) and replayable read models from day one, not as a later refactor.
• The initiative is a pilot, an internal system, or a bounded domain where a small-community dependency is an acceptable risk.

Look elsewhere when:

• You need a dedicated, battle-tested event store with strong global ordering, very high write throughput, or multi-language consumers — evaluate EventStoreDB, Marten (.NET), or a Kafka-based log instead.
• Your stack is not Ecotone and you are unwilling to adopt it. Do not treat this as a drop-in PDO event store for a Symfony/Laravel app; the integration surface is the framework.
• You require a vendor SLA, commercial support, or a clear license. The license resolves to NOASSERTION, which needs legal review before adoption; a package that is a read-only mirror also means issues and fixes route through a separate monorepo.
• Ecosystem maturity matters more than feature fit. Eight stars and zero dependents is a signal about third-party validation, not code quality — but it means you will be an early adopter, hiring will be hard, and answers will come from docs and source rather than community.
• You need guaranteed versioning discipline. Pin explicitly and inspect the release history of the parent ecotone/ecotone package; maturity currently reads as documentation-only on this package page.
• Your team has no event-sourcing experience. The framework reduces boilerplate, not the conceptual load (idempotency, eventual consistency, projection lag, replay safety).

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a low-cost option to add event sourcing and durable workflows to a PHP system using the PostgreSQL or MySQL database we already run, instead of standing up a new event-store platform. The strategic value is optionality — we can introduce audit trails and multi-step workflows now and grow into full event sourcing later without rewriting the codebase. The primary risks are vendor/community maturity (a young ecosystem with little third-party adoption), an unclear license that requires legal sign-off, and the fact that it only pays off if we commit to the Ecotone framework. Recommendation: treat it as a time-boxed pilot on one bounded domain, with a documented exit path, not a platform-wide standard.

For engineering leadership: The package gives us the commodity parts of event sourcing — aggregate repository, upcasting for schema evolution, projections with replay, and durable sagas — backed by PDO, so no new operational surface. The cost is adoption of Ecotone's attribute-driven programming model and a small dependency ecosystem; we should pin versions, own the operational runbook for projection lag and replay, and validate the license. Success criteria for the pilot: p95 command latency at expected write volume, replay correctness on a schema change, and a saga surviving a mid-flight process restart.

For the delivery team: Day one can look like ordinary command handlers; event sourcing is enabled per-aggregate. That keeps the learning curve incremental and lets us ship value before committing the whole domain.