Business Logic Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy (scaffolding): The package generates boilerplate classes via Artisan "makers." Release 1.1.0 adds MakeSpecification and MakeRule, extending generation beyond generic classes into two named domain patterns. This tips the decision toward buy/adopt rather than maintaining in-house stub files per repository — the cost of ownership is a Composer dependency instead of a shared internal package with its own release cycle.
• Architecture roadmap: Choosing to standardize on the Specification pattern (composable query/eligibility objects) and the Rule pattern (encapsulated business rules) is a real architectural commitment. This package lowers the adoption cost by making the "right" structure the path of least resistance for every engineer.
• Feature decisions this enables: Pricing and discount eligibility, entitlements/feature gating, per-tenant validation policies, and complex filter/search composition — all areas where rules change often and need to be individually testable and reviewable. Having a canonical Rule class shape makes it feasible to expose rule configuration to admins later without a rewrite.
• Refactor vs. tolerate: If the team is debating whether to pull logic out of fat models/controllers into discrete, testable units, the existence of a one-command scaffold materially changes the effort estimate in that conversation.
• Onboarding and review cost: Opinionated generators encode team conventions, which reduces PR churn and code-review debate about where logic lives.

When to Consider This Package

Adopt when:

• You are on Laravel/PHP with an existing Artisan-driven workflow, and developers already reach for make:* commands daily.
• Two or more teams, services, or repositories need the same class conventions — a shared package beats copy-pasted stubs that silently drift.
• You have (or are about to have) a meaningful volume of business rules or query specifications — roughly the point where hand-writing ten-plus of these becomes a recurring tax.
• You want generated code that stays plain, framework-idiomatic PHP: no runtime dependency, no lock-in, easy to remove later.

Look elsewhere or skip when:

• You do not intend to use the Specification or Rule patterns; the added makers are only valuable if the patterns are actually adopted.
• The codebase is small — a handful of hand-written classes is cheaper than a dependency plus version pinning.
• You already own an internal generator package, or you lean on Blueprint/Pest/IDE templates that cover the same ground.
• You need a runtime rule engine (evaluation, DSL, configurable predicates). This is code generation, not execution — a common stakeholder misread worth correcting early.
• Maintenance signals are weak and the generated output is trivial to reproduce; the whole value proposition rests on consistency, not capability.

Adoption hygiene: pin the version, verify the PHP/Laravel support matrix against your oldest supported app, and write a short ADR plus a convention doc — otherwise the generators produce classes nobody agrees on how to use.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk engineering dependency that standardizes how we write business rules and query logic. The 1.1.0 release adds generators for two patterns we care about — Specification (composable, reusable query/eligibility logic) and Rule (single, named, unit-testable business rules). The payoff is measurable in two places: less engineering time spent on boilerplate, and business logic that is individually testable and reviewable — which matters for pricing, entitlements, and eligibility logic where mistakes are expensive and audits are likely. There is no runtime dependency and no lock-in: generated classes are ordinary PHP we own outright, so reversing the decision costs almost nothing.

For engineering: 1.1.0 adds make:specification and make:rule alongside the existing makers. Use them to scaffold composable specifications for filtering/eligibility and discrete rule objects for business policy. Recommended rollout: adopt on one team for a sprint, standardize on the Specification pattern for a single subsystem (e.g., catalog filtering), then document the convention and expand. Pair the generators with tests from day one — the point of a Rule class is that it is independently assertable. Constraint to keep in mind: this generates structure, not behavior; do not let it be sold internally as a rules engine.