Yadm Bundle Laravel Package

Product Decisions This Supports

• Choose-your-ODM architecture decision for MongoDB-backed services. Yadm is a lightweight document mapper positioned against Doctrine MongoDB ODM: less abstraction, faster hydration/persistence, fewer moving parts. This package is the Symfony integration layer for that choice — the decision it informs is "Doctrine ODM vs. thin custom mapper" for read-heavy or high-write-throughput collections.
• Build vs. buy for a persistence layer. The relevant evaluation is not "adopt this bundle" but "is our MongoDB data access a differentiating concern or plumbing?" If it's plumbing and Doctrine's identity map/Unit of Work overhead is hurting p95 latency, a thin mapper is a legitimate build/buy fork worth costing out.
• Performance-driven roadmap prioritization. If profiling shows hydration dominating request time on hot endpoints (catalogs, feeds, event ingestion, read models), this is evidence to fund a persistence optimization workstream rather than a feature workstream.
• Use-case fit: read-mostly projections and CQRS read models, high-volume write ingestion, denormalized documents where you control the schema and don't need Doctrine's relationship/event machinery, and bounded-context services where a full ODM is overkill.
• Framework-strategy reality check. This is a Symfony bundle, not Laravel. If the product surface is Laravel, this package is out of scope by construction — the parallel decision is whether to adopt jenssegers/mongodb-style Eloquent integration or a framework-agnostic mapper instead. Flagging this early prevents wasted spikes.

When to Consider This Package

Consider only if all of the following hold:

• The service is Symfony (4.x-era given the 2019 release date) and will stay there.
• You have measured hydration/persistence as the bottleneck, not assumed it.
• Your documents are simple, schema-controlled, and you can live without Doctrine ODM's Unit of Work, change tracking, references, and lifecycle events.
• You are prepared to vendor/fork and own the code — treat it as a reference implementation, not a dependency.

Look elsewhere if any of these are true:

• Maintenance risk is disqualifying. Last release 2019-05-14, 7 stars, 0 dependents, near-zero community signal. No security response path, no PHP 8.x/Symfony 6+ compatibility guarantee, no upstream bugfix velocity. A single-maintainer, dormant package at the core of your persistence layer is an unacceptable bus-factor.
• You need Doctrine ODM features — relations, embedded document handling, events, migrations tooling, a hiring pool that knows it.
• The stack is Laravel or framework-agnostic PHP. Bundle is Symfony-specific and won't compose.
• You want ecosystem support — IDE integration, documentation, Stack Overflow answers, third-party bundles.
• The performance gap is unproven. Doctrine ODM with tuned projections and a proper read model usually closes most of the perceived gap; benchmark before rewriting.

Default recommendation for most teams: do not adopt as a dependency. Use it as a design reference if you're evaluating a custom mapper, and benchmark the actual delta first.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a thin MongoDB persistence layer for Symfony that trades Doctrine's conveniences for raw speed. It's technically interesting but effectively abandoned — no release since 2019, negligible adoption, a single maintainer. Adopting it would move a core system onto unmaintained code with no security or compatibility path, which is a risk we shouldn't underwrite for a performance gain we haven't yet measured. Recommendation: do not adopt; instead, spend a short spike measuring whether Doctrine ODM is actually our bottleneck, and revisit a thin mapper only if the numbers justify owning that code ourselves.

For engineering (bullets):

• It's a Symfony bundle, not Laravel — out of scope for our Laravel services entirely.
• Value proposition is real: less abstraction, faster hydration than Doctrine ODM. Value is conditional on measurement.
• Cost of ownership is the whole story: dormant since 2019, 0 dependents, 7 stars. As a dependency it's a liability; as a reference design for a ~300-line internal mapper it's useful reading.
• Next step: profile our hottest MongoDB read paths. If hydration is <15–20% of request time, close this thread. If it's dominant, scope an internal thin-mapper POC rather than a package adoption.
• Decision owner: platform/backend lead. Timebox: one spike, one sprint.