Persistence Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the persistence layer. The package is a thin Symfony bundle wrapping funddy/persistence — a repository/unit-of-work abstraction for DDD-style aggregates. Its real value to a PM is as a reference implementation when deciding whether to hand-roll a repository abstraction or adopt a maintained one (Doctrine repositories, spatie/laravel-data, custom Eloquent repositories).
• Architecture standardization on the roadmap. If the team is debating "should our domain layer know about the ORM?", this codebase is a concrete, readable example of the answer (aggregate roots, collection-oriented repositories, transactions at the boundary). Useful input to an ADR, not a commitment.
• Not a vendor-selection or dependency decision. 3 stars and 0 dependents is a disqualifying signal for anything load-bearing. Do not let this appear on a "candidate libraries" shortlist for a production system.
• Ecosystem-fit triage. Despite the "Laravel/PHP" framing, this is a Symfony bundle, not a Laravel package. That mismatch alone generates integration cost (service container wiring, bundle registration, no Laravel service provider) that a PM should price in before anyone prototypes with it.

When to Consider This Package

Consider it only when:

• You are already on Symfony and already depending on funddy/persistence (in which case this bundle is the mandatory glue, not a choice).
• You want a 30-minute read of a small, focused DDD persistence implementation to inform an internal design — treat it as documentation, not a dependency.
• You are explicitly evaluating a fork: small surface area, permissive license, and self-contained code make a fork-and-own viable if the pattern fits.

Look elsewhere when:

• You are on Laravel. Use Eloquent with dedicated repository classes, or spatie/laravel-data + custom query objects. There is no Laravel-native path through this bundle.
• You need maintained support: security patches, PHP 8.x/9 compatibility, framework version upgrades, or an issue tracker someone reads. Zero dependents and single-digit stars mean no downstream pressure to fix anything — you will be the only one maintaining it.
• Your persistence needs are conventional CRUD. A DDD repository abstraction is overhead you will pay for in indirection and onboarding time; ActiveRecord is the cheaper answer.
• Compliance or SLA obligations exist — unmaintained transitive dependencies are a supply-chain and audit liability.

Decision rule for the PM: adoption requires a named owner willing to fork and maintain, and an existing Symfony/funddy/persistence footprint. Absent both, the answer is no.

How to Pitch It (Stakeholders)

To executives: This is a tiny, unmaintained, Symfony-specific persistence library with effectively zero adoption. We are not proposing to depend on it. We are proposing to spend a few hours reading it as a design reference while we decide how our domain layer talks to the database — a decision that affects maintainability and hiring, not this quarter's roadmap. Estimated cost: under a day. Estimated risk if we instead adopted it: ongoing maintenance ownership we did not budget for, on code nobody else uses.

To engineering: Treat funddy/persistence-bundle as a pattern sample, not a dependency. It demonstrates repository + unit-of-work boundaries for aggregate-oriented persistence in Symfony. If the pattern wins, we implement it ourselves against our own ORM — roughly a sprint of work with full ownership — rather than inheriting an unmaintained bundle that will need a fork on day one. If we are on Laravel, this is an ecosystem mismatch and out of scope entirely.

Recommendation: Reference only. Do not add to composer.json.