Product Decisions This Supports
- Enhanced Data Integrity: Enables immutable, regex-validated value objects (e.g.,
Email, CreditCard, CustomID) to replace loose string inputs, reducing runtime errors and security vulnerabilities (e.g., SQL injection via malformed IDs).
- Domain-Driven Design (DDD) Adoption: Aligns with DDD by encapsulating business rules (e.g., "only valid ISO dates") within domain objects, improving code clarity and maintainability.
- Build vs. Buy Tradeoff: Avoids reinventing regex validation logic while offering customization (e.g., adding new patterns via composition). Lower dev cost than bespoke solutions.
- Security Hardening: Mitigates risks like XSS (via strict input sanitization) or invalid API payloads by validating at the object level before processing.
- Roadmap Enablers:
- API Contracts: Integrate with OpenAPI/Swagger for schema validation (e.g., enforce regex patterns in API specs).
- Localization: Extend patterns for global markets (e.g., international phone numbers, multilingual IDs).
- Performance: Benchmark against alternatives (e.g.,
Respect/Validation) for high-throughput systems (e.g., payment processing APIs).
When to Consider This Package
-
Adopt if:
- Your Laravel app requires complex regex validation (e.g., custom ID formats, niche data standards like ISO 8601 timestamps).
- You’re using DDD and want to enforce invariants at the value-object level (e.g.,
InvoiceNumber must match /INV-\d{8}/).
- Your team prioritizes type safety and immutability over Laravel’s built-in
Validator (e.g., for critical paths like auth or payments).
- You need MIT-licensed, lightweight code with minimal dependencies (only PHP 8.3+ required).
-
Look elsewhere if:
- Your validation needs are simple (e.g., basic email/URL checks) and Laravel’s
Validator suffices.
- You lack internal documentation or need enterprise support (this package has 0 stars/dependents; assess risk tolerance).
- Your team prefers active maintenance (e.g.,
spatie/laravel-validation-rules or Respect/Validation).
- You’re on PHP <8.3 or Laravel <10 (requires upgrades).
How to Pitch It (Stakeholders)
For Executives:
"This package lets us fail fast on invalid user input (e.g., ‘only valid emails or credit cards’) by embedding validation rules into the code itself—like TypeScript for strings. It’s a low-risk way to reduce bugs and security flaws in APIs/data pipelines. For example, instead of catching malformed IDs at the database layer, we’d reject them upfront. Alternative: Build custom validators (higher dev cost) or use Laravel’s built-in tools (less precise). We’d prototype with 1–2 high-impact fields (e.g., auth tokens) before scaling."
For Engineers:
*"RegexValueObjects gives us immutable, validated value objects (e.g., Email, Password) with zero runtime regex errors. Key wins:
- No more
preg_match spaghetti: Replace repetitive validation with reusable objects.
- Cleaner domain models: Enforce rules like
new Email($input) throws if invalid.
- Extensible: Add custom patterns via composition.
Tradeoffs: Minimal docs (we’d need to explore the monorepo), but the API is simple. Let’s start with a proof of concept for critical validations (e.g., API keys) before committing."*
For Developers:
*"Imagine replacing:
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { ... }
With:
$email = new Email($rawInput); // Throws on invalid format
This makes validation self-documenting and reusable. Start with high-impact fields (e.g., auth, payments) to test its value. We’ll need to build Laravel adapters (e.g., for FormRequest rules), but the core logic is straightforward."*