Laravel Laravel Package

Technical Evaluation

Architecture fit. ecotone/laravel is the Laravel adapter for Ecotone, a PHP messaging runtime supplying command/query buses, event handling, aggregates, sagas, projections, and a transactional outbox. From a TPM's standpoint the question is not "is this good technology" but "does the roadmap actually require these primitives." It fits when the product has genuine domain complexity — cross-module workflows, auditable event history, multi-step business processes, or a planned modular-monolith evolution. It does not fit when the real need is background jobs, which Laravel's queue, jobs, and Event::dispatch already handle with far less conceptual overhead. Worth flagging explicitly for stakeholders: Ecotone's primary integration target is Symfony; Laravel is a secondary surface, so Laravel-specific edge cases are likely lower priority upstream. This is an architectural accelerator, not a customer-facing differentiator, and should be sold internally as such.

Integration feasibility. The mechanical install is cheap: Composer, publish config, service-provider auto-discovery, attribute-driven handler registration, artisan commands (ecotone:list, ecotone:run). The real project is converting existing service-layer/CRUD code into command/query/event flows — that is where the estimate lives, and it should be scoped and staffed as a refactor, not a dependency addition. One correctness question dominates feasibility: whether the adapter reuses Laravel's DB connection and transaction manager so that state commits and domain events share a transaction. If they don't, you inherit a class of consistency bugs that no amount of handler code fixes.

Technical risk — high. Three items gate the decision, not merely inform it:

• License risk: NOASSERTION is not a license grant. Legal review is a hard gate before any code merges; treat an unresolved license as a stop condition, not a cleanup task.
• Adoption risk: 22 stars and 0 dependents means effectively zero field validation. Your team will encounter the edge cases first, and there is no peer ecosystem to borrow fixes from.
• Irreversibility: event stores, outbox tables, and published event schemas are a long-lived data commitment. Backing out is a migration, not a refactor — budget for it in the decision memo.

Add bus-factor concentration on a low-traffic upstream project as a standing risk to track in the risk register.

Key questions for the maintainers (route through engineering, but own the answers as decision inputs):

1. Supported Laravel and PHP version matrix, and how quickly constraints widen after a Laravel release?
2. Octane/Swoole compatibility — is the container and handler registry safe under long-lived workers?
3. Does it integrate with Horizon and standard queue drivers as message channels, or does it require its own transport config?
4. Outbox relay mechanics — polling loop, scheduled command, or queue-driven — and what delivery guarantee results?
5. Are event store, outbox, and saga-state migrations published by the package?
6. Written license clarification.
7. Release cadence, CVE handling, and whether commercial support exists and explicitly covers the Laravel adapter.

Integration Approach

Stack fit. Viable on Laravel 10/11 with PHP 8.2+ on MySQL or Postgres. Because the adapter is thin, most stack-fit risk belongs to Ecotone core — direct engineering to evaluate core at least as carefully as the adapter. Poor fit where the team relies on Octane, exotic queue drivers, or heavily customized container bindings; a secondary adapter is exactly where those lag.

Migration path. Strangler-fig, never a rewrite. Select one bounded context — ideally new or low-traffic, with natural event semantics (notifications, order lifecycle, onboarding). Keep Eloquent read models. Route new writes through an Ecotone command bus while legacy controllers and jobs stay untouched. Move the outbox and projection layer last, once handler correctness is proven. This keeps the blast radius of an abandoned pilot to one context.

Compatibility. Pin both ecotone/ecotone and ecotone/laravel explicitly and treat the adapter's declared constraints as the ceiling for future Laravel upgrades. Budget for upgrade lag on both sides simultaneously — this is the most likely source of unplanned work in year two, and the TPM should carry it as a standing roadmap line item rather than an engineering surprise. Do not depend on Laravel features the adapter does not declare support for.

Sequencing (each step a go/no-go gate):

1. License and version-matrix verification — hard stop if unresolved.
2. Sandbox spike: one command, one event, one handler, one projection, end to end.
3. Failure validation: kill a worker mid-transaction, force duplicate delivery, confirm idempotency and outbox recovery.
4. Staging pilot of the chosen bounded context under realistic load.
5. Production pilot behind a feature flag with a documented rollback.
6. Expand-or-abandon review against criteria agreed before step 1.

The success criteria and exit criteria in step 6 must be written before step 1 — otherwise the pilot becomes the adoption by default.

Operational Impact

Maintenance. You are now operating two runtimes with two release cadences. Reconciling Laravel upgrades against Ecotone releases needs a named owner with allocated capacity, not a shared team responsibility. Assume you will pin, patch, or fork; if you fork, price it as a permanent headcount commitment in the roadmap, because it is one.

Support. Community-scale only. With zero dependents there is no peer ecosystem to borrow fixes or patterns from — the documentation and the maintainers are the entire support surface. Confirm commercial support availability before committing, and confirm in writing that it covers this adapter, not just core.

Scaling. Consumers scale horizontally like queue workers, but event-sourced aggregates and projections add write amplification and ordering constraints that plain workers don't have. The outbox relay is an additional always-on process and a first-class operational dependency — fund it, monitor it, and name an owner. Projection rebuilds should be treated as routine operations with a documented, rehearsed procedure and a maintenance window, not as an emergency runbook.

Failure modes to design for (this list is the TPM's risk register for the pilot):

• Silent handler non-registration — attribute discovery fails after a config or namespace change and messages vanish with no error. The most dangerous failure here because it is quiet. Require a startup assertion and health check.
• Poison messages with no dead-letter path, blocking a consumer indefinitely.
• Outbox relay lag or stall, producing a domain that is internally consistent but externally stale with no visible alarm.
• Duplicate delivery against non-idempotent handlers.
• Partial commits splitting state from its domain event.
• Adapter/core version mismatch at upgrade time.

Ramp-up. Steep: messaging, DDD, and event-sourcing concepts stacked on an unfamiliar adapter. Expect weeks, not days, before a competent Laravel developer is independently productive, and several sprints before the team reasons confidently about failure semantics. This requires a senior champion and a design-review gate, with training budgeted explicitly — under-resourcing ramp-up is the most common way these initiatives fail quietly rather than loudly.

Bottom line for the steering decision: the capability is real and there is no first-class Laravel-native equivalent for sagas, aggregates, and a transactional outbox. But at 22 stars, zero dependents, and an unresolved license, this is a bet on a thin adapter to a secondary platform. Approve it only behind a strict license gate and a narrow, reversible pilot with pre-agreed exit criteria — and be prepared to own the fork.