Product Decisions This Supports
- Architecture-level decisions, not feature-level ones. Nihilus is a thin CQRS (Command Query Responsibility Segregation) component — commands, command buses/handlers, queries, and query buses. It does not ship product features; it shapes how the team structures domain logic. Treat it as an enabling library for decisions like whether to split write and read models.
- Auditability and reporting roadmaps. CQRS makes it natural to introduce an append-only write side and derived read models. If your roadmap includes an audit trail, activity feed, "who changed what" views, or compliance reporting, this is the architectural seam that supports it without retrofitting later.
- Read/write scaling decisions. If one part of the product is write-heavy (checkout, bookings, order intake) and another is read-heavy (dashboards, catalog, search), CQRS lets you optimize and scale each side independently. This informs the "do we invest in separate read store / caching layer?" decision.
- Segment-specific read models. Different user segments (ops staff, finance, customers) can get purpose-built projections instead of one compromised query layer. That is a product-shape decision — it affects what dashboards and exports you can ship cheaply.
- Build vs. buy vs. roll-your-own. Because the library has zero dependencies and is small in scope, it makes a useful reference implementation for a build decision: read it, decide whether to adopt, vendor, or fork. The dependency footprint matters if your product sells into security- or procurement-constrained environments (smaller supply-chain surface to justify).
- Complex multi-step workflows. If a product decision involves workflows with validation, side effects, and multiple consumers (e.g., "submit claim → validate → notify → project"), command handlers give a clean, testable unit of behavior that product and engineering can discuss in shared language.
- Not supported: this package gives you none of the hard parts of CQRS for free — no event store, no projections, no eventual-consistency tooling, no message transport. Any roadmap that depends on those needs a separate decision.
When to Consider This Package
Consider it only if all of these are true:
- You have already decided to use CQRS. This package does not justify the pattern; the pattern justifies the package.
- The team is on PHP/Laravel and wants a minimal, dependency-free command/query bus rather than a framework-coupled solution.
- You are prepared to vendor or fork it. With a last release of 2019-11-29, 7 stars, and 0 dependents, you should assume no upstream maintenance, no security patches, and no community answers. The right mental model is "small open-source codebase we take ownership of," not "library we depend on."
- The codebase is small enough to review fully (a weekend of reading, not a quarter).
- You value a low dependency count more than ecosystem support — e.g., regulated, air-gapped, or long-lived products where supply-chain provenance is a sales or compliance requirement.
Look elsewhere if any of these are true:
- You need active maintenance, a release cadence, or a hiring-friendly skill on the CV.
prooph, EventSauce, Ecotone, Broadway, or spatie/laravel-event-sourcing have orders of magnitude more adoption and documentation.
- You need the surrounding infrastructure — event store, projections, sagas, async transport, retries, dead-letter handling. Nihilus does not provide it, and you will end up building it.
- Your team is not already fluent in CQRS/DDD. The bus is the easy 5%; the consistency, versioning, and migration problems are the other 95%, and a 7-star package offers no guidance.
- You want a supported Laravel-native path — Laravel's own bus/queue plus
Symfony Messenger semantics will be easier to onboard and debug.
- You would be adding your first CQRS usage on a schedule. Introducing an unmaintained library and a new architectural pattern simultaneously doubles the risk; pick one.
- The dependency-risk conversation with security/procurement would be harder than the benefit of zero dependencies. In most SaaS contexts, "abandoned since 2019" loses that argument.
How to Pitch It (Stakeholders)
To executives: This is an architectural component, not a product feature — it doesn't ship anything visible to customers. It matters because it underpins capabilities we may want later: audit trails, clean financial/operational reporting, and independent scaling of heavy writes vs. heavy reads. However, my recommendation is not to adopt it as a dependency today. It is an abandoned, low-adoption library (last release 2019, single-digit stars, no downstream users). The pattern is valuable; this implementation is a maintenance liability. If we want it, we take the code, own it, and budget accordingly — or we use a maintained alternative for similar effort.
To engineering: Nihilus is a zero-dependency PHP command/query bus built by Wynd. Pros: tiny, readable, no framework lock-in, negligible supply-chain surface — genuinely useful as a reference or a vendored starting point. Cons: unmaintained since November 2019, no community, no security process, and it deliberately stops at the bus. Every hard CQRS problem (event store, projections, idempotency, replay, schema evolution) is ours to solve. Recommendation: timebox a spike. Read the source, prototype one bounded context, and compare against Ecotone or spatie/laravel-event-sourcing on the same slice. Adopt only if the team explicitly accepts ownership and forks it into our own namespace with our own tests and release process.
One-line ask: Approve a two-week evaluation spike (not adoption) to validate whether the CQRS pattern earns its complexity in our domain — the package choice is a follow-on decision, and this package is unlikely to be the answer.