In a CQRS codebase, every component eventually faces the question: can I dispatch a command or a query from here? The answer is almost never obvious, and most discussions online either say "yes, always" or "never except controllers", without explaining the reasoning behind either position.
A domain event describes something that already happened. It is a fact, not an intention. Yet many codebases publish events from inside the entity, at the moment its state changes, which couples the entity to infrastructure and lets you announce a fact before it is even true in the database.
Most architecture discussions treat the bus question as global. Either the whole application routes commands and queries through a CQRS bus, or none of it does. That framing forces a bad trade: pay CQRS boilerplate on a homepage that displays a greeting, or drop the bus on a module that genuinely needs events and transactions. The real unit of decision is not the application. It is the module.
In most PHP projects, cache logic ends up scattered across business code. The handler that executes the query also contains the caching logic: key generation, lookup, storage, TTL. Two responsibilities, cache code and business code, coexist in the same method.
In most PHP projects, transaction management falls on the developer. But a forgotten DB::transaction() or a missing rollback, and the data sometimes ends up in an inconsistent state.