Rich Model Forms Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for form-to-domain mapping. If the roadmap includes admin/back-office CRUD, onboarding, or checkout flows backed by DDD-style models (value objects, private constructors, typed collections), this bundle replaces the bespoke DataMapper classes you would otherwise write and maintain per form. That is a concrete, recurring engineering cost you can strike from sprint planning.
• Whether to keep domain models "pure." It operationalizes the decision that form concerns (setters, arrays, string casting) must not leak into entities. Adopting it is a signal that the team commits to rich models and keeps UI/persistence adapters at the edge.
• Refactor vs. rewrite of legacy models. Because mapping lives in the form layer, you can convert anemic entities into rich models form-by-form without rewriting controllers — a viable incremental tech-debt path rather than a big-bang rewrite.
• Feature scoping for complex forms. Value-object inputs (Money, Email, DateRange), nested collections with add/remove semantics, and constructor-only models are exactly where this saves time. If those forms are on the roadmap, this is a delivery lever.
• Platform caveat that may end the discussion: despite being surfaced as a "Laravel/PHP" package, it is a Symfony bundle tied to the Symfony Form component. In a Laravel codebase it delivers zero value.

When to Consider This Package

Evaluate or adopt when:

• You are on Symfony and already using the Form component.
• Domain models are genuinely rich, and you refuse to add form-friendly setters to them.
• You have several forms over value objects or immutable constructors, and hand-written data mappers have become repeated boilerplate.
• You accept the maintenance reality: last release March 2020, ~217 stars, small community. Verify compatibility with your Symfony/PHP versions before committing, and plan to vendor or fork.

Look elsewhere when:

• You are on Laravel or any non-Symfony framework — not applicable.
• Models are simple entities with getters/setters; the default mappers are sufficient.
• You need vendor-backed support, security-patch SLAs, or guaranteed Symfony 6/7 compatibility.
• The team standardizes on API Platform, DTOs + serializer, or custom validators, so Symfony Forms are not the input layer.
• The need is one-off; a single custom data mapper is cheaper than a dependency.

How to Pitch It (Stakeholders)

Executives: A free (MIT), small-footprint library that removes repetitive glue code between our forms and our domain models. It keeps business logic clean and speeds delivery of complex forms. The catch: no release since 2020, so we treat it as "adopt-and-own" and may fork it. Lock-in is low because the surface area is small.

Engineering: It provides ready-made data mappers for constructor-only models, value objects, and collections, so we stop hand-rolling DataMapperInterface implementations. Recommended path: spike it on one bounded context, confirm Symfony version compatibility, and be prepared to vendor the small codebase if upstream stays dormant.