Simple Data Transfer Object Laravel Package

Product Decisions This Supports

• Boundary contracts (feature-level): Use it to decide whether your app standardizes on typed DTOs at the edges — HTTP request → service → response, job/event payloads, webhook ingestion, and config hydration — instead of passing associative arrays through layers. A simple DTO base class is the cheapest way to test that discipline before committing a team to it.
• Build vs. buy/adopt: This package is the "adopt a tiny base class" option in the DTO space — minimal ceremony, MIT, Laravel-oriented, no heavy feature surface (validation, nested hydration, collections are deliberately thin). The strategic decision it informs is: adopt a thin DTO layer, fork/vendor one, or write 40 lines of readonly-class boilerplate in-house.
• Roadmap risk triage: The archived status, 9 stars, 0 dependents, and a last release of March 2024 are the real product signal here. The decision it supports is containment: is this a low-blast-radius internal utility we can own, or does it sit on a critical path where "no maintainer" becomes a roadmap liability?
• Use cases where it fits: internal admin tools, back-office services, small Laravel apps, test fixtures, and one-off integration adapters where a typed constructor-hydrated object with array/JSON serialization is enough and you don't want a framework-sized dependency.
• Migration/refactor decisions: If you're cleaning up array-passing in a legacy module, this gives you a small, reversible step — easy to swap for spatie/laravel-data or native PHP 8 readonly classes later, because the surface area is small.

When to Consider This Package

• Consider it when: you're on Laravel/PHP 8+, you want a minimal DTO base (typed properties, hydration from arrays, serialization back to arrays/JSON, maybe casting), the use case is internal or non-critical, and you're comfortable treating the package as source you own — fork it, vendor it, pin it, and accept that you are the maintainer.
• Look elsewhere when: the DTO layer touches money, auth, PII, or public API contracts; you need active security patching, LTS guarantees, or community support; you need validation built in, nested/recursive hydration, collections, attribute-based mapping, or guaranteed compatibility with newer Laravel/PHP releases (Laravel 11/12, PHP 8.3/8.4).
• Stronger defaults: spatie/laravel-data (validation + nested DTOs + Laravel integration), spatie/data-transfer-object (simpler, but also in maintenance mode), WendellAdriel/validated-dto, or plain PHP 8 readonly classes with constructor property promotion — which for a "simple" DTO is often the whole feature set anyway.
• Decision gate: archive status + zero dependents means no external bug pressure. If the answer to "who fixes this when PHP 9 breaks it?" is "us, and we're fine with that," adopt. Otherwise, don't.

How to Pitch It (Stakeholders)

To executives: A small, MIT-licensed helper for structuring data moving through a Laravel app — the kind of utility that reduces "array soup" bugs at low cost and zero vendor spend. It is not a strategic dependency: the project is archived and has essentially no adoption, so we'd treat it as internal code we own rather than a supported library. Recommendation: fine as a low-risk internal convenience, not appropriate for anything customer-facing or security-sensitive.

To engineering: A thin DTO base — typed properties, hydration from arrays, serialization back out — without the weight of a full data-mapping framework. Small surface area, easy to fork and pin, easy to replace with native PHP 8 readonly classes or spatie/laravel-data if requirements grow. Caveat: unmaintained and archived, so we take on patch duty; adopt deliberately, keep it off critical paths, and don't build deep abstractions on top of it.