Product Decisions This Supports
- Build vs. buy for domain-layer validation. Laravel's
Validator is a presentation-layer tool: it throws/fails fast, speaks in attribute strings, and drags the HTTP request lifecycle into whatever calls it. This package offers a framework-agnostic, exception-free alternative. The real decision it informs is not "which validator" but "where does validation live in our architecture" — controller/FormRequest, or domain command/value object.
- Notification pattern vs. fail-fast. Because errors accumulate into a collection rather than short-circuiting, it supports products where a user or API consumer needs the complete set of problems in one response (bulk importers, multi-field wizards, CSV ingestion, config linters, queue jobs reporting per-row failures). That's a UX and support-cost decision, not just a code-style one.
- Roadmap scoping for a framework-independent core. If there's any ambition to expose the same validation rules through a non-HTTP surface — CLI, queue worker, gRPC/JSON API, or a future service extraction — a dependency that carries no Illuminate baggage is a prerequisite. This package is a cheap way to prototype that boundary before committing to it.
- Extraction/modernization sequencing. It gives a concrete, low-risk unit of work for teams pulling logic out of controllers ("move these rules into typed command objects that return a notification list"). Useful as the first slice of a larger strangler-fig effort because it's reversible.
- Use cases where it fits cleanly: domain commands, value-object construction, importer/ETL row validation, config and manifest checking, and any test suite that wants to assert on a structured error collection instead of catching exceptions.
- Strategic note for the record: this is not a Laravel package. There is no service provider, no facade, no
unique/exists/password rules, no localization. Adopting it is an explicit decision to own the integration glue and the rule catalog ourselves.
When to Consider This Package
Adopt when all of the following hold:
- You have (or are deliberately creating) a domain layer that must not depend on Laravel, and validation is currently leaking framework types into it.
- You genuinely need aggregate error reporting rather than first-error-wins.
- The rule set required is self-contained and expressible in plain PHP — no database-backed uniqueness checks, no file/MIME inspection, no locale-aware messages.
- Your team is comfortable treating it as a thin primitive that you wrap behind an internal
ValidatorInterface, keeping the swap cost near zero.
- You're willing to accept that you are the maintainer of the last mile: rule wrappers, message catalog, translation, and Laravel wiring all live in your codebase.
Look elsewhere when:
- The work is ordinary CRUD. Laravel's built-in validator plus FormRequests already solves this with zero new dependencies, first-class localization, and DB-aware rules. Replacing it here is churn for architectural purity nobody asked for.
- You need ecosystem guarantees. 35 stars and zero dependents means no community backstop, no third-party rule ecosystem, no track record of security advisories being triaged. For anything on a regulated or long-lived critical path, that is a real cost — budget for vendoring or a fork.
- You need the message/i18n surface. Translation, pluralization, human-friendly attribute names: you will build this yourself.
- Bus factor matters and you can't absorb it. One maintainer, no visible contributor base. Fine for a 200-line concept; a liability if it becomes load-bearing.
- You need Laravel-native ergonomics —
Rule::unique(), after hooks, nested array validation with dotted attribute paths, validated() output.
A reasonable middle path: treat it as a reference implementation. The notification pattern is ~a few hundred lines; copying the pattern into your own src/Domain/Validation buys the architectural benefit without the external dependency.
How to Pitch It (Stakeholders)
To executives (one line): A small, MIT-licensed pattern library that lets us validate business rules outside the web framework and report all problems at once instead of the first one — low cost, low risk, but also low leverage; it's a tactical dependency, not a platform bet, and we should only take it if we've already decided our domain code needs to be framework-independent.
To engineering: It's a framework-agnostic validator built on the notification pattern — validation returns an error collection instead of throwing or short-circuiting. That's genuinely better ergonomics for domain commands, importers, and any non-HTTP entry point. The trade-offs are explicit: no Laravel integration (we write the service provider binding), no database-aware rules, no localization, tiny maintainer base. So the plan is to wrap it behind our own ValidatorInterface on day one, keep our rule catalog in-house, and preserve a one-afternoon exit to a fork or an in-house implementation. If we can't commit to that wrapper, we shouldn't adopt it.
Recommendation: Adopt only as a scoped pilot in one bounded context where the domain layer is already being extracted. Do not adopt as a replacement for Laravel validation in existing CRUD flows — the migration cost is real and the benefit there is marginal.