Laravel Tactician Laravel Package

Product Decisions This Supports

• Adopt vs. build vs. borrow-the-pattern. The real decision this artifact informs is whether to introduce a command bus (CQRS-lite) into a Laravel codebase so that controllers stay thin and business logic lives in single-purpose handlers resolved from the service container. The package itself is only one of three answers; here the strongest answer is "borrow the pattern."
• Architecture roadmap. It is the lever to pull when the backlog is full of symptoms rather than features: fat controllers, god-services, inconsistent application of transactions, authorization, logging, and queuing around the same operations. A command bus turns those into one middleware pipeline instead of N copy-pasted blocks.
• Feature scoping / capacity allocation. Command-bus plumbing is non-differentiating infrastructure. Whether it is bought, adopted, or built in-house is purely a question of engineering hours — which is exactly the kind of trade a PM should force into the open rather than let it happen implicitly inside a refactor ticket.
• Dependency portfolio and tech-debt triage. The package is archived, last released 2016-04-10 (v1.0.0), targets Laravel 5, and has 5 stars. That makes it a useful data point for a dependency-health review: it belongs on a "reference only / do not install" list, not in composer.json.
• Concrete use cases it describes well (and which justify the pattern regardless of the package): order and checkout flows, multi-step onboarding and approval state transitions, form-heavy admin operations, and any workflow where one user action maps to one handler with a consistent set of cross-cutting concerns.
• Reference-spec value. The integration surface is small — a service provider, a publishable config for the command bus and handler mappings, and a dispatch() entry point. Reading it is a cheap way to price an internal build (realistically a few hundred lines) and to write acceptance criteria for it.

When to Consider This Package

Treat "consider" here as consider reading and reimplementing, not consider installing.

Look at it when:

• You are maintaining a legacy Laravel 5.x application on an old PHP runtime and need container-resolved command handlers with middleware, and you cannot introduce modern dependencies.
• You want a worked, minimal example of wiring league/tactician into Laravel's container, config, and package auto-discovery before writing your own provider.
• You intend to fork and own the code outright, with a named internal maintainer and a documented upgrade path.

Look elsewhere — which covers essentially every other case — when:

• You are on Laravel 6/8/10/11+. This package targets Laravel 5 and is archived; compatibility is not maintained. Use league/tactician directly behind a thin service provider, or use Laravel's own bus (Illuminate\Bus\Dispatcher, dispatchable jobs, pipelines), which already gives you container resolution, middleware, queueing, retries, and batching.
• You need queued or async commands, retries, or failure handling — Laravel's job/bus layer solves this natively; Tactician plus this wrapper does not.
• Security, compliance, or long-term-support review applies. Archived code with a single historical maintainer and no patch stream fails a standard dependency review, and 5 stars means there is no community to surface bugs.
• You expect vendor support, an upgrade policy, or a version-compatibility matrix. None of these exist here.
• The capability is expected to evolve with the product. Coupling core workflows to an archived adapter guarantees a forced migration later, on someone else's schedule.

Caveat on the framing: a 1.0.0 tag is normally a credibility signal, but here it is a 2016 tag on a repository that has since been archived. The stable-release milestone should not be read as current maintenance evidence; the archival status supersedes it.

How to Pitch It (Stakeholders)

For executives: This is not a package we should install. It is archived, its last release was in 2016, it supports Laravel 5 only, and it has effectively no user base — so it carries maintenance and security risk while offering no support path. What it does give us is a clear, cheap blueprint for a piece of internal structure: a command bus that keeps controllers thin and makes cross-cutting concerns like authorization, transactions, and logging consistent instead of hand-rolled per feature. Recommendation: decline the dependency, fund a small, time-boxed internal implementation (or use Laravel's built-in bus, which is already in the framework), and treat this repository as documentation. The ask is measured in engineering days, not in an ongoing vendor relationship, and it directly reduces the cost of every future workflow feature.

For engineering: Do not add tillkruss/laravel-tactician to composer.json. The integration is roughly a service provider, a config file mapping the command bus and handlers, middleware pipeline support, and a dispatch() convenience — a small enough surface to own outright. Preferred path on a modern Laravel version is the framework's native bus and queued jobs, optionally with league/tactician underneath if we want an explicit command/handler split. If we do build a custom bus, isolate it behind our own interface and adapter so the implementation can change without touching feature code. Verification for the spike: handler resolution from the container, one middleware (transaction or authorization), one queued command with retry behaviour, and a documented extension point. Success criteria and a rollback path before we touch a production workflow.