Use Case Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow on application-layer plumbing. This package is not a feature; it is a convention for structuring business operations ("use cases") as discrete, container-resolved classes in a Laravel app. The decision it informs is whether to standardize that shape across teams versus ad-hoc service classes, Laravel Actions (lorisleiva/laravel-actions), or plain command/handler wiring.
• Module and team boundaries. A one-class-per-use-case convention gives you a defensible unit for code review, ownership, and later extraction into modules or services. That directly supports roadmap decisions about how to slice a growing monolith without a rewrite.
• Test strategy and quality investment. Use cases as entry points make it cheap to write one acceptance test per business capability rather than per controller or per Eloquent model. This is an argument for funding test coverage in the application layer specifically.
• Onboarding and delivery velocity. A uniform shape for business logic shortens the ramp for new engineers and reduces "where does this logic live?" debates — a real but unglamorous productivity lever.
• Cross-team contracts. If adopted, use case signatures become the interface between feature teams and shared domain code, which supports decisions about API stability and internal versioning.
• What it does not support: pricing, packaging, customer-facing differentiation, or any externally visible roadmap item. Treat any proposal to adopt this as an internal architecture decision with an internal ROI case.

When to Consider This Package

Consider it when:

• Your team has already committed (or is genuinely willing to commit) to hexagonal/clean architecture, command-handler separation, or an interactor pattern, and wants a thin Laravel-native primitive rather than a framework.
• You are greenfield or early in a modular monolith, where conventions can be set cheaply and consistently.
• You have an owner willing to fork and vendor it. This is the gating criterion, not a footnote.
• You want a small, readable reference implementation of the pattern to copy or adapt internally.

Look elsewhere when:

• You need community support, an SLA, a compatibility matrix, or evidence of production use. Zero stars, zero dependents, and a single-vendor origin mean there is no field-tested path — you would be the first.
• You need breadth: queue integration, sagas, event sourcing, or a mature bus. Use Laravel's pipeline/queues directly, Laravel Actions, or Symfony Messenger.
• Your team is small and shipping fast. The indirection costs more than it returns before you have real domain complexity (YAGNI applies hard here).
• Your architecture is already settled; adding a second convention creates divergence, not consistency.
• Verify before any pilot: package metadata shows a last release of 2026-03-04, which is anomalous relative to today. Treat that as a data-quality flag and confirm actual release history, PHP/Laravel version constraints, and whether the repository is maintained or archival. A future-dated release with zero dependents is exactly the profile of an internally-used library published once and left alone.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-risk internal experiment in standardizing how business logic is written — not a customer-facing bet. The investment is a few engineer-days plus a named owner; the payoff is faster onboarding, cleaner module boundaries, and cheaper refactoring later. Adoption risk is real but contained: MIT license, small surface area, and we can fork it if the upstream goes quiet.

To engineering: The value is the convention, not the code — the library is thin enough that we could reproduce it ourselves in a couple of hundred lines. It gives us one boring, consistent shape for business operations, keeps logic out of controllers, and makes each capability independently testable through the container. The honest caveat: no community, no dependents, no support. So the ask is a time-boxed spike on one bounded context, with an explicit decision gate — adopt-and-fork (pinned, vendored, with an internal owner) or replicate the pattern in-house and drop the dependency. Either outcome is a win as long as we decide deliberately rather than drift into it.