Formula Doctrine Bundle Laravel Package

Product Decisions This Supports

• Derived/Computed Fields: Enable read-only, dynamically computed properties (e.g., orderCount, totalSpent, lastActivityDate) without physical database columns, reducing schema complexity and storage costs.
• Performance Optimization: Mitigate N+1 query issues by leveraging SQL subqueries/aggregations at the ORM level, improving query efficiency for common derived metrics.
• Domain-Driven Design (DDD): Align entity models with business logic by encapsulating calculations (e.g., Customer::getLifetimeValue()) directly in the entity layer, avoiding service-layer boilerplate.
• Roadmap for Analytics: Accelerate development of reporting features (e.g., dashboards, admin panels) by pre-computing metrics in entities rather than post-processing data.
• Build vs. Buy: Avoid custom Doctrine event listeners or DQL hydration logic, reducing technical debt and maintenance overhead.
• Use Cases:
  • E-commerce: Product::getStockStatus(), Order::getTaxTotal().
  • SaaS: User::getSubscriptionTier(), Project::getActiveTasks().
  • Analytics: Report::getPeriodicMetrics() without materialized views.

When to Consider This Package

• Avoid if:
  • Your team lacks PHP/Symfony/Doctrine expertise (low adoption, minimal documentation).
  • Computed fields require write operations (this is read-only only).
  • You need complex caching strategies (e.g., stale-aware formulas) beyond basic query-time computation.
  • Your use case demands real-time updates (formulas are resolved on entity load, not via triggers).
  • You’re using non-Doctrine ORMs (e.g., Eloquent, Propel).
• Look elsewhere if:
  • You need materialized views or database-level computed columns (e.g., PostgreSQL GENERATED ALWAYS AS).
  • Your formulas require PHP logic (this is SQL/DQL-only).
  • You’re in a high-scale environment where SQL subqueries introduce performance risks (profile first).
• Consider when:
  • You’re already using Symfony + Doctrine and want to reduce N+1 queries.
  • Your team prefers declarative over imperative solutions for derived data.
  • You need lightweight, MIT-licensed dependencies with no vendor lock-in.

How to Pitch It (Stakeholders)

For Executives:

"This bundle lets us add dynamic, read-only fields to our database models (e.g., ‘order count’ or ‘customer lifetime value’) without extra database columns or slow N+1 queries. It’s like adding computed properties to your entities—cleaner code, faster queries, and no schema changes. Think of it as ‘Google Sheets for your database,’ but built into Symfony. Low risk (MIT license), high reward for analytics and reporting features."

Key Ask: "Can we pilot this for [X high-impact metric] to reduce backend complexity and speed up dashboard development?"

For Engineering:

*"The Formula Doctrine Bundle integrates Hibernate-style #[Formula] annotations into Symfony, enabling SQL/DQL-based computed fields in Doctrine entities. Key benefits:

• No physical columns: Avoids schema migrations for derived data.
• Automatic hydration: Formulas resolve on entity load (no manual DQL hydration).
• Performance: Uses subqueries/joins to eliminate N+1 queries for common metrics.
• Symfony-native: Wires Doctrine listeners via DI, reducing boilerplate.

Trade-offs:

• Read-only (no writes to formulas).
• SQL/DQL only (no PHP logic).
• Minimal community (but MIT license and active repo).

Proposal: Use this for [specific use case, e.g., User::getActiveSubscriptionDays()] to replace [current workaround]. Benchmark against alternatives like custom Doctrine listeners."*

Next Steps:

1. Spike: Test with a non-critical entity (e.g., Product::getDiscountedPrice).
2. Compare performance vs. materialized views or application-layer calculations.
3. Document patterns for caching/stale data (if needed)."