Data Transfer Objects Laravel Package

Product Decisions This Supports

• Build vs. buy (DTO layer): This is a capability reference, not a dependency candidate. It demonstrates a pattern — typed, immutable objects replacing associative arrays at request, service, and job boundaries — which is a decision you will make regardless of whether you adopt this specific library. Treat it as a spec you can read in ~30 minutes, not a package you install.
• Architectural roadmap: Supports the decision to formalize contracts between layers (HTTP → Domain → Persistence, or module boundaries in a modular monolith). DTOs are the cheapest enforcement mechanism for "no arrays crossing module lines," which directly affects how expensive future refactors are.
• Feature scoping for validation & serialization: If the package's hydration/validation approach (array/JSON → typed object, nested DTO casting, collection hydration) matches your needs, it defines the acceptance criteria for a homegrown version — a 1–3 day build, not a 3-week one.
• Legacy modernization sequencing: Useful as a before/after artifact when justifying incremental strangler-style refactors — showing stakeholders concretely what "we replaced a 40-key array with a typed contract" looks like.
• Standards decisions: Informs your team convention on immutability, readonly properties, constructor validation vs. validator classes, and whether DTOs are also your API Resources or a separate layer.

When to Consider This Package

Consider it when all of the following hold:

• You want a compact, opinionated DTO implementation with no framework coupling beyond plain PHP/Composer, and you've read the source and found it small enough to audit in an afternoon.
• You are forking or vendoring it deliberately — accepting ownership of maintenance — because MIT licensing and a small surface make that practical.
• You need a reference implementation for a pattern your team is debating, and reading a production-derived package is faster than writing a design doc.

Look elsewhere — or build in-house — when any of the following apply, which is the default case here:

• You need a supported dependency. 4 stars, 0 dependents, and a single-vendor origin (TenantCloud's own SaaS) mean the bus factor is effectively one. There is no community to surface bugs, no CVE response process you can rely on, and no guarantee the next major Laravel/PHP release is tracked. Your composer.lock is a supply-chain and upgrade-cost decision; this is a one-way door for the modules that depend on it.
• You want ecosystem depth. Mature alternatives in this exact space (spatie/laravel-data, spatie/data-transfer-object, cerbero/dto, wendelladriel/validated-dto) offer validation integration, Laravel container/route-model binding, TypeScript generation, and documented upgrade paths. For a commodity capability like DTOs, the "buy" side of build-vs-buy has a clear winner and the differentiation available from a niche package is near zero.
• You need runtime casting of complex types (collections, enums, nested arrays, date handling with timezone semantics) — verify parity carefully against incumbents before committing; these are the exact edge cases where thin packages leak.
• Your team is small or the codebase is young. The opportunity cost of owning a bespoke DTO layer is real; adopt the boring, popular option and spend the saved effort on product.

Recommendation: Do not add as a production dependency. Do evaluate as a design input alongside spatie/laravel-data, and default to the incumbent unless this package demonstrates a specific, load-bearing advantage you can articulate in one sentence.

How to Pitch It (Stakeholders)

To executives: We evaluated an open-source PHP library for structuring data as it moves between systems. It is technically reasonable but has essentially no adoption (4 GitHub stars, zero downstream dependents) and is maintained as a by-product of one company's internal product. Adopting it would make us the de facto maintainers of a component we don't want to own. The capability it provides is commodity — the market leader is well-supported and free. Recommendation: no new dependency, no budget impact; use it as a design reference and standardize on the established alternative. Net cost of the decision: near zero. Net risk avoided: an unsupported component in the critical path of every request.

To engineering: Read the source for the pattern, not for the install. It's a useful illustration of typed, immutable payloads replacing arrays at layer boundaries, and a sanity check on how little code a DTO layer actually requires. If we build in-house, scope it to 1–3 days against the criteria this package implies: constructor-time typing, array/JSON hydration, nested and collection support, and no framework coupling. If we buy, spatie/laravel-data is the default. Either way, the deliverable is a team convention on where DTOs live and what may not cross a boundary as an array — that convention is the actual value, and it is independent of this package.