Domain Structures Laravel Package

Product Decisions This Supports

• Build vs. buy for domain primitives. If the roadmap includes a modular monolith, bounded-context extraction, or a service rebuild, this package is a "buy" for the boilerplate layer — shared base Record / Value Object / DTO / TypedCollection classes — instead of every team hand-rolling constructors, equality checks, and toArray().
• Feature sizing and scope. Type safety at the HTTP → DTO → domain seam is a recurring line item in nearly every API feature. A package like this converts it into a convention, which shortens estimates, shrinks per-PR review surface, and reduces boundary bugs (loose arrays, stringly-typed IDs).
• Roadmap sequencing. Adoption is cheap in greenfield and inside a context you're already extracting; it is a migration epic in a legacy codebase. That cost asymmetry belongs in the planning conversation, not in the backlog by accident.
• Architecture standards / ADR input. This is a candidate "house style" for value objects, IDs, enums, and typed lists — decide once, apply everywhere, rather than three teams independently picking three DTO libraries.
• Onboarding and consistency cost. Fewer bespoke base classes means less code a new hire must read and more uniform PRs across teams.
• Lifecycle/tech-debt planning. If adopted, the vendor API becomes an internal contract; version bumps and forks become planned work with an owner, not a surprise.
• Explicitly out of scope for this decision: money/currency semantics, validation rule engines, ORM mapping, and API serialization policy. Those remain separate build/buy calls and should not be subsumed by a general toolkit.

When to Consider This Package

Consider it when:

• You are starting a greenfield Laravel service or extracting a bounded context, and the team is already comfortable with DDD-lite conventions.
• You are visibly paying the "where do DTOs live and what shape are they" tax — inconsistency is producing real defects.
• You want one opinionated vocabulary (Record / VO / DTO / TypedCollection) rather than assembling four or five micro-packages with overlapping semantics.
• You can vendor or fork it. The MIT license makes that legally trivial, and the surface area appears small enough to own internally if the maintainer disappears.

Look elsewhere or hold when:

• Maturity signals are the deciding factor. Zero stars, zero dependents, a single maintainer: there is no external evidence of production use, no community security review, and no track record of surviving Laravel major-version upgrades. That is a material risk for anything customer-facing or long-lived.
• You need proven serialization and validation — spatie/laravel-data or first-party casts and validators are the safer default.
• Money, currency, or date handling is involved — use moneyphp/money, brick/money, Carbon. Do not let a general-purpose toolkit own correctness-critical semantics.
• Procurement or platform standards require dependency hygiene, SBOM review, or a support contract. There is no vendor to call.
• The team is junior or unfamiliar with DDD terminology — the conceptual overhead can outweigh the safety gained.
• You are on an older Laravel/PHP baseline; verify the version constraint before anything else.

Recommended posture: time-boxed pilot in one internal or back-office service, governed by an ADR, with a written exit plan (fork path, or fallback to spatie/laravel-data + native casts) before it touches the core domain.

How to Pitch It (Stakeholders)

Executive summary. A small MIT-licensed PHP library that standardizes how domain data is shaped — records, value objects, DTOs, typed collections. This is a conventions-and-boilerplate play, not a platform bet. The value shows up as fewer boundary defects on API work, faster delivery on features that cross layers, and less bespoke code to maintain. License cost is zero; the real costs are adoption discipline and a modest dependency risk.

Engineering summary. It gives us a shared vocabulary and base classes so teams stop re-implementing constructors, getters, equality, and toArray() — and it enforces types at the HTTP-to-domain seam where most of our data-integrity bugs originate. State the caveats plainly: the package is pre-traction (0 stars, 0 dependents, single maintainer). Therefore we pin versions, vendor or fork it, and keep it away from money and date semantics. Run a time-boxed pilot in one service behind an ADR, and keep a documented fallback to spatie/laravel-data plus native casts if the API churns or maintenance stalls.

The one-line ask: approve a scoped pilot, not a standard. We get the ergonomics evidence now and retain the option to make it the house style later — or to walk away at near-zero sunk cost.