Common Laravel Package

Product Decisions This Supports

• Standardization of Query Logic: Enables consistent, reusable query patterns across Laravel/PHP projects using Doctrine ORM, reducing duplication in data access layers.
• Adoption of Specification Pattern: Facilitates modular, composable query logic (e.g., and/or/not specifications) for complex filtering in APIs, admin panels, or reporting tools.
• Legacy System Modernization: Accelerates refactoring of monolithic Doctrine query logic into maintainable, abstracted components, improving long-term scalability.
• Build vs. Buy Decision: Justifies customization of an open-source package (MIT license) over building proprietary query abstractions, given its lightweight design.
• Roadmap for Query Abstraction: Aligns with a phased migration strategy to replace ad-hoc DQL or QueryBuilder logic with a standardized specification pattern.

When to Consider This Package

• Adopt if:
  • Your Laravel project heavily uses Doctrine ORM (not Eloquent) and requires reusable, composable query logic.
  • You prioritize internal consistency over external dependencies and are willing to maintain the package long-term.
  • Your team is familiar with Doctrine DQL and the specification pattern, or willing to invest in learning curves.
  • You’re modernizing legacy systems with spaghetti DQL queries and need a lightweight abstraction layer.
• Avoid if:
  • Your project relies on Eloquent or prefers Laravel’s Query Builder over DQL.
  • You require active maintenance (package is archived; no updates or community support).
  • Existing solutions (e.g., Doctrine Criteria, Laravel Scout, or API Platform) already meet your needs.
  • Your team lacks Doctrine expertise or the bandwidth to debug undocumented abstractions.

How to Pitch It (Stakeholders)

For Executives: "This package offers a lightweight, MIT-licensed way to standardize complex database queries in our Laravel apps using the specification pattern. By adopting it, we can reduce technical debt in data access layers, improve query reusability, and align with our goal of modularizing backend logic. While the package is archived (low stars/dependents), its simplicity and MIT license make it easy to fork or extend if needed. The trade-off is minimal upfront cost for long-term maintainability gains, especially in high-query-volume features like admin panels or reporting tools."

For Engineering: *"The DoctrineManager abstract class and and/or/not specifications let us compose queries declaratively (e.g., UserRepository::findBy($spec->and($spec1, $spec2))). This is ideal for:

• Admin panels with dynamic filtering (e.g., multi-criteria searches).
• APIs needing reusable query logic (e.g., pagination, sorting).
• Legacy refactors to replace spaghetti DQL with modular components. Downsides: No active maintenance, but the MIT license and simple design make it easy to fork. Let’s prototype it in [Project Y] to validate fit before wider adoption. We’ll need to:

1. Bind the DoctrineManager to Laravel’s EntityManager via a service provider.
2. Test performance against native DQL/QueryBuilder.
3. Document patterns for team adoption."*