Data Model Laravel Package

Product Decisions This Supports

• Build vs. Buy: Buy – Eliminates manual DTO construction, validation, and hydration logic, reducing technical debt and accelerating development cycles. Ideal for teams prioritizing maintainability and type safety.
• Feature Roadmap:
  • API Layer: Standardize request/response DTOs across microservices, reducing serialization/deserialization complexity.
  • Data Migration: Safely transform legacy data (e.g., databases, APIs) into typed objects with minimal boilerplate.
  • Validation Layer: Replace ad-hoc validation logic (e.g., in Laravel Form Requests) with declarative Describe attributes, centralizing rules.
  • Domain Modeling: Enforce business rules (e.g., pre/post hooks) directly in data models, reducing service-layer complexity.
• Use Cases:
  • Laravel Ecosystem: Replace manual fill() calls or Arrayable/Jsonable traits with type-safe hydration (e.g., converting API responses to Eloquent models or custom DTOs).
  • Event-Driven Systems: Ensure event payloads are validated and typed before dispatching/consuming (e.g., #[Describe(['required' => true])] on event properties).
  • CLI/Config Parsing: Hydrate CLI arguments or config files into strongly typed objects (e.g., Config::from($_ENV)).
  • Testing: Generate test data with guaranteed structure (e.g., User::from(['name' => 'Test']) vs. manual object assembly).

When to Consider This Package

• Adopt if:

  • Your team struggles with boilerplate in DTOs (e.g., repetitive isset() checks, manual casting).
  • You need runtime validation without coupling to frameworks (e.g., Laravel Validation, Symfony Validator).
  • Type safety is critical but manual hydration introduces bugs (e.g., missing properties, incorrect casts).
  • You’re building composable data pipelines (e.g., transforming API responses → domain objects → database records).
  • Static analysis (PHPStan, Psalm) is a priority—this package surfaces all resolution rules via attributes.

• Look elsewhere if:

  • You’re using Symfony Serializer or JMS Serializer and already have a mature serialization strategy.
  • Your data models are trivial (e.g., no validation/casting needed) and manual hydration is negligible.
  • You need performance-critical hydration (this package uses reflection, which adds overhead).
  • Your team lacks PHP 8.1+ (attributes, union types) or prefers annotation-based solutions (e.g., Doctrine ORM).
  • You’re in a Greenfield project with no existing DTOs—consider Laravel’s built-in casting or Spatie’s Data Transfer Objects first.

How to Pitch It (Stakeholders)

For Executives:

"This package lets us write less code while reducing bugs in how we handle data. Instead of manually wiring API responses or database rows into objects—with all the isset() checks, type casts, and validation rules scattered across constructors—we declare the rules once, in a single attribute. This cuts development time by 30–50% for DTOs and makes our data layer self-documenting and verifiable. For example, a User DTO that previously required 15 lines of constructor logic can be defined in 3 lines with #[Describe]. It also future-proofs our API contracts by embedding validation rules directly in the type system."

ROI:

• Faster development: No more copy-pasting hydration logic.
• Fewer bugs: Runtime validation catches issues early (e.g., missing required fields).
• Lower maintenance: Rules are colocated with properties, not spread across services.
• Scalable: Works for simple APIs, complex domain models, and even CLI/config parsing.

For Engineering Teams:

*"Problem: Our DTOs are a mess of manual hydration, duplicated validation, and magic strings. Every time we add a new field or change a type, we risk breaking consumers. Solution: zero-to-prod/data-model gives us declarative, type-safe hydration with:

• Zero boilerplate: Replace User::fromArray($data) with User::from($data).
• Centralized validation: Define required, cast, and default values next to the property (no more scattered logic).
• Recursive hydration: Automatically instantiate nested objects (e.g., User::from(['address' => [...]])).
• Hooks for business logic: Use pre/post hooks to enforce rules (e.g., reject negative ages).
• Static analysis: All resolution rules are visible to IDEs and tools like PHPStan.

Migration Path:

1. Start with critical DTOs (e.g., API request/response models).
2. Replace manual fill() calls with from().
3. Gradually adopt validation hooks (e.g., pre for domain rules).
4. Use DataModelHelper for collections (e.g., User::fromArray($users)).

Trade-offs:

• Reflection overhead: ~10–20% slower than hand-written hydration (benchmark before production use).
• Learning curve: Team must adopt #[Describe] attributes (but pays off quickly).
• Not a silver bullet: For ultra-high-performance needs, hand-optimize later.

Next Steps:

• Spike: Convert 1–2 DTOs to use DataModel and measure dev time saved.
• Pair with: zero-to-prod/data-model-helper for collections, transformable for output formatting.
• Integrate with: Laravel Validation (see examples) to reduce duplicate rules."*

Key Selling Point for Engineers: "This is like Laravel’s Eloquent models, but for DTOs. You get all the magic (hydration, validation, casting) without the ORM overhead."