Symfony Bundle Laravel Package

Technical Evaluation

Architecture fit. Despite the "Laravel/PHP package" framing, this is a Symfony bundle only — there is no Laravel service provider, no framework-agnostic core, and hard dependencies on FrameworkBundle, SecurityBundle, Twig, Doctrine ORM, Symfony Messenger, and OverblogGraphQLBundle. Architecturally it is not a library but an opinionated platform starter: it ships base classes (AggregateRoot, DomainMessage, ValueObject, UuidId, ValueObjectCollection), a full CQRS/ES runtime on top of Prooph Event Store, projections into Doctrine read models, GraphQL type/query/mutation scaffolding, plus two production concerns you would normally build yourself (session idle-expiry enforcement and maintenance mode with a pre-kernel gate). For a team already committed to Symfony + Messenger + Overblog GraphQL + event sourcing, the fit is high because it removes months of glue code. For anyone else, including any Laravel shop, fit is effectively zero — the reusable surface shrinks to a handful of leaf utilities (ContentDisposition, PasswordStrength, StringUtil, some value objects).

Integration feasibility. Low-to-moderate, and gated on inspection rather than documentation. The bundle is not self-contained by its own admission: the post-make:model checklist instructs you to edit App\Projection\Table and App\Messenger\RunProjectionMiddleware, which are host-application classes, not bundle classes. That means the scaffolded output assumes a specific app skeleton the bundle does not ship — you will be reverse-engineering one team's internal project template from a Maker command. Maintenance mode additionally requires editing the front controller to call MaintenanceGate::handleGlobals() before the kernel boots, which is an invasive, per-project change. Session expiry is on by default and requires sessions plus SecurityBundle. Treat adoption as "fork a platform," not "install a dependency."

Technical risk.

• Upstream dependency risk (highest). The event store is the system of record. Prooph components are effectively dormant/archived upstream — verify current status and whether XM ships its own forks. Migrating an event store off an unmaintained library is expensive and touches every aggregate.
• Bus factor and adoption signal. 0 stars, 0 dependents, no external consumers. There is no community compatibility evidence, no third-party issue triage, and no pressure to preserve backward compatibility. Every upgrade is a bespoke migration you own.
• Release/versioning hygiene. Last release is dated 2026-10-28 — a future date relative to normal evaluation windows. Verify whether this is a metadata anomaly or a genuine forward-dated tag before trusting the version history. Confirm the license, a SECURITY.md, and whether tags follow semver.
• Coupling breadth. A single package that also owns session behaviour, HTTP-level maintenance responses, and GraphQL error-code contracts couples infrastructure, security, and API surface into one upgrade unit. A breaking change in maintenance mode forces a release you must absorb even if you only use the ES layer.
• Toolchain currency. PHP 8.1+ strict types, PHPUnit 13 with attributes, PHPStan, Rector, php-cs-fixer with => alignment — modern and disciplined, but it means your CI must match theirs to consume generated code cleanly.

Key questions to resolve before any commitment.

1. Can the CQRS/ES core be used without Overblog GraphQL (i.e., is the GraphQL layer optional or hard-wired into the Maker and projections)?
2. Which Symfony major/LTS versions are actually tested in CI, and is the matrix published?
3. Are Prooph dependencies forked, pinned, or vendored — and what is the stated plan if upstream stays dormant?
4. Is there a supported path to run make:model outside an XM-shaped app (does it emit the App\* couplings or read them from config)?
5. What is the license, and are external PRs/issues accepted at all?
6. What is the event-store schema and migration story — Doctrine schema tool, hand-written migrations, or neither?

Integration Approach

Stack fit. Target stack is Symfony 6/7, Doctrine ORM, Symfony Messenger, Twig, and OverblogGraphQLBundle, with PHP 8.1+. If the evaluating team is on Laravel, stop at a spike: port ContentDisposition and the value-object primitives by hand and discard the rest. If on Symfony but GraphQL-free, the ES/CQRS layer may still be viable — confirm the coupling in question 1 first.

Migration path. Do not adopt wholesale on a first attempt. Three viable options, in ascending order of commitment:

• Reference implementation (recommended first step). Read the Maker output and the aggregate/message base classes as a design template; copy the patterns into your own thin internal package. Keeps you off the fork treadmill and lets you drop Prooph if needed.
• Cherry-pick utilities. ContentDisposition (non-ASCII filename handling Symfony's HeaderUtils refuses), PasswordStrength, StringUtil, and the UuidId/ValueObject primitives are low-risk, high-value, and lift cleanly.
• Fork and own it. Only if you are building a greenfield Symfony platform and accept full ownership. Use a VCS/path repository with an exact pinned tag, not a floating ^ constraint.

Compatibility work to budget for.

• Composer install plus a config/packages/xm_symfony.yaml for session_expiry and maintenance toggles.
• Front controller modification for the pre-kernel maintenance gate.
• Prooph event-store schema creation on your target database (verify on your actual DB engine, not just MySQL).
• Event stream creation via bin/console event-store:event-stream:create per bounded context.
• GraphQL schema dump (app:graphql:dump-schema) wired into CI, or the schema silently drifts.
• CI parity for PHPStan/Rector/php-cs-fixer if you intend to keep generated code under the same rules.

Sequencing.

1. Spike in a throwaway Symfony app: install, run make:model once, read 100% of the generated output, and run the test suite.
2. Verify Prooph installs and the event store persists/replays on your target stack.
3. Port one real, low-risk bounded context end to end (command → aggregate → event → projection → GraphQL query) and measure the manual-step checklist in practice.
4. Decide: adopt as platform, cherry-pick patterns, or reject. Only then allow a second bounded context.
5. If adopting, pin the tag, add a smoke test that boots the kernel with maintenance on and off, and document the front-controller change as an owned deviation.

Operational Impact

Maintenance. You inherit nearly all of it. With no external dependents there is no compatibility contract, no deprecation policy, and no guarantee of timely releases; make:model output and the documented manual steps can change without notice. The heaviest long-term liability is the event store: any decision to leave Prooph is a data migration across every stream, and projection rebuilds are the only safety net. Budget for one engineer to own the fork and track Symfony major upgrades.

Support. Single-vendor, internal-origin code with an AGENTS.md tuned for AI agents rather than a public support process. Expect no SLA, no issue triage, and no security advisories feed. Escalation means contacting the originating team directly or self-supporting.

Scaling. The read side scales conventionally — projections are Doctrine tables, so you add read replicas and indexes as usual. The write side scales by partitioning event streams per aggregate and horizontally scaling Messenger workers; watch for projection lag under load and plan snapshotting before streams get long. Maintenance mode's worker behaviour is actually well designed for operations — workers pause in-place between messages rather than exiting, avoiding supervisor restart loops. Session expiry adds a cheap per-request check but is security-relevant: any long-poll or status endpoint must set _extend_session: false or it will keep sessions alive indefinitely; conversely, remember-me sessions never expire, which may or may not match your policy.

Failure modes worth instrumenting.

• Maintenance file loss on deploy. The gate file must survive deploys; if it does not, you cannot turn maintenance off cleanly and stale .html artefacts linger.
• Metadata enricher exceptions blocking writes. IP/user-agent/issuer enrichment runs on the write path — a proxy or header change can fail event persistence.
• Projection desync and replay failures from non-deterministic aggregate logic or unversioned event payloads.
• GraphQL schema drift when the dump command is skipped in CI.
• Maintenance key leakage — the key travels in a query string, then a cookie; ensure it is stripped from logs and referrers.
• Session expiry surprises for polling clients and dashboards.

Ramp-up. A mid-level Symfony developer needs roughly two to four weeks to be productive on the ES/CQRS conventions (protected constructors, static factories, command/event pairing, projection wiring) and longer to be safe with event versioning and replay. make:model compresses the boilerplate significantly, but the seven-step post-generation checklist — repository config, projection config, stream creation, App\Projection\Table, RunProjectionMiddleware mapping, GraphQL permissions, schema dump — is entirely manual and app-coupled; that is where onboarding time and defects will concentrate. The dense AGENTS.md is a genuine asset for AI-assisted work, provided the agent has repository access and your team reviews generated code rather than trusting it. Net: attractive as an internal platform accelerant for a Symfony/GraphQL/ES shop that is prepared to fork; not viable as a general-purpose dependency.