Data Mapper Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the object-mapping layer. The underlying need — decoupling persistence entities from API resources, request payloads, and domain objects — is real and recurring. This package is a data point in that evaluation, not a viable answer to it.
• Whether to standardize DTO/mapping conventions now or defer. Introducing a mapping layer early shapes API contracts, versioning strategy, and how much controller-level glue code accumulates. This package forces that conversation but should not close it.
• Dependency vetting policy. With 0 stars, 0 dependents, and no release since February 2016, this is a textbook case for a written adoption gate: maintenance status, supported PHP/Symfony ranges, security response, and test coverage.
• Framework fit. The name is data-mapper-bundle: it is a Symfony bundle (kernel-registered, service-container wiring), not a Laravel package. For a Laravel product, this is a non-starter on architecture alone, independent of its age.
• Legacy triage, not roadmap. The only product decision it can meaningfully inform is "do we have a legacy Symfony 2.x/3.x app already wired to this?" — and with zero dependents recorded, even that is unlikely.
• Use cases the pattern serves (and which you should still solve): request validation → domain command mapping, entity → API response shaping, versioned public API contracts, and isolating domain models from ORM and transport concerns.

When to Consider This Package

Adopt only if all of the following hold — realistically, never for new work:

• You maintain an existing Symfony application that already depends on this bundle and where removal cost currently exceeds the risk.
• The app is pinned to PHP 5.x/7.0-era runtimes and Symfony 2.x/3.x, with no upgrade path in the planning horizon.
• You have vendored or forked it and can carry maintenance internally.

Look elsewhere — or build — if any of these are true (all are true for most teams):

• You are on Laravel. Bundles are not a Laravel concept; there is no service-container integration path, and no expectation of Laravel-idiomatic conventions.
• You need a maintained release, a security contact, PHP 8.x support, or any dependency with a public issue tracker that gets answered.
• Your team relies on transitive community support: 0 stars and 0 dependents means no Stack Overflow corpus, no blog posts, and no peers to consult when behavior is surprising.
• You want the mapping pattern without the package: Symfony Serializer with normalizers, jolicode/automapper, CuyZ/Valinor, or spatie/laravel-data and Laravel API Resources on the Laravel side.

Adoption criteria worth encoding in a checklist: a release within 12 months, an explicit supported-version matrix, CI status visible, a security policy, and at least a modest dependent base. This package fails all five.

How to Pitch It (Stakeholders)

For executives: We evaluated thruster/data-mapper-bundle for the data-mapping layer and recommend against it. It was last released in February 2016, has no recorded users or downstream dependents, and is built for a different framework (Symfony) than our stack. Adopting it would mean owning abandoned third-party code indefinitely — a standing maintenance and security liability with no offsetting feature benefit. The problem it addresses is legitimate; we should solve it with actively maintained tooling as part of normal feature work, at low incremental cost.

For engineering: The pattern is worth keeping — an explicit mapping boundary between persistence models, domain objects, and API resources pays off in testability and API stability. The package is not. It is a Symfony bundle (not Laravel-compatible), unmaintained since 2016, effectively unknown to the ecosystem, and almost certainly targets PHP 5.x/7.0 and Symfony 2.x/3.x. Recommendation: a short spike (1–2 days) to prototype the mapping layer with Symfony Serializer or spatie/laravel-data, whichever matches our framework, and land it behind an interface so the implementation stays swappable. Document the adoption gate we used here so future "small utility package" decisions are consistent and fast.