Product Decisions This Supports
- Whether to add an event layer to your command bus at all. This package exists to answer a specific product-architecture question: should domain side effects (audit trails, notifications, cache invalidation, read-model projections, analytics) be triggered by events emitted from the bus rather than inlined inside command handlers? It is a concrete, low-cost way to prototype that pattern before committing to it.
- Build vs. buy for bus instrumentation. The package is small enough that "buy" is really "adopt a naming convention." Assessing it forces the right decision: implement events as a thin Tactician middleware in-house (~100 lines you control) versus pulling in a 2015-era dependency. For most teams the answer is build, and this package is the reference spec for what to build.
- Use-case validation for cross-cutting concerns. Use it to enumerate which stakeholder-visible features actually need bus-level events: compliance/audit logging, customer notifications on state change, search-index sync, webhook fan-out, metrics on command volume and failure rates. If none of those are on the roadmap within two quarters, the pattern isn't worth the indirection.
- Roadmap sequencing against a bus migration. Since the package is stale, evaluating it surfaces the real decision: if you are on Tactician now, is the strategic path to stay and hand-roll events, or migrate to Symfony Messenger (native events + middleware) or Laravel's queue events? That migration question outranks this package.
- Not supported: it does not inform pricing, packaging, or customer-facing feature bets. Its blast radius is internal architecture.
When to Consider This Package
Consider it only when all of the following hold:
- You are already running
league/tactician in production and are not planning to move off it within the current planning cycle.
- You need published, subscribable events around command execution (pre/post/failure) rather than direct method calls.
- Your PHP version and Tactician version are compatible with the package's 2015 constraints — verify this first; the constraint set predates PHP 7.1+ idioms and is the most likely hard blocker.
- You accept it as vendored/read-only reference code rather than a maintained dependency. With 14 stars, zero dependents, and a last release of 2015-12-31, there is effectively no maintenance, no security response, and no community to absorb breakage.
- The cost of the pattern failing is low — i.e., it sits behind an internal interface you could swap for your own middleware in a day.
Look elsewhere, or build in-house, when:
- You are on Symfony Messenger (native events, active maintenance) or Laravel (its event dispatcher and job middleware already do this; layering a second bus abstraction is net-negative complexity).
- You need long-term support, security patching, or a supply-chain story your platform team will sign off on. An unmaintained 2015 package with zero dependents will fail most dependency-review gates on those grounds alone.
- You want durable, replayable domain events. This is an in-process hook, not an event store — do not let it be mistaken for event sourcing.
- You need ordering, delivery guarantees, retries, or observability beyond what a synchronous in-process callback gives you.
- Your team has no existing Tactician investment — adopting a dormant bus plus a dormant plugin to get an event layer is strictly worse than adopting a maintained bus that ships events.
How to Pitch It (Stakeholders)
To executives: This is a small, free, MIT-licensed PHP add-on that lets our command bus announce "this action is about to happen / just happened / failed" so separate parts of the product — audit logs, customer notifications, search, analytics — can react without being wired into every feature. The strategic value is the pattern, not the package: it lets us add compliance-grade audit trails and customer-facing notifications as plug-ins rather than one-off code in each feature.
To engineering: Treat it as a design reference, not a dependency. It is 14 stars, zero dependents, last released December 2015, and has no maintainer — it will not survive our dependency review and should not be on the critical path. Recommendation: spend a day writing an equivalent middleware against our own CommandBus interface, which gives us the same pre/post/failure hooks with code we own, test, and can version. The genuine decision to make is upstream of this package: whether we invest further in Tactician or plan a move to Symfony Messenger or Laravel's bus, which provide events natively. Decision requested: approve the in-house middleware (est. 1–2 days) and defer the bus-migration question to next quarter's architecture review.
Risk if adopted as a runtime dependency: unmaintained code in the request path, no security response, and a future migration blocked by a package nobody owns.