[5.3] Allow for splitting commands and handlers on jobs. #14897
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request allows for commands and handlers (whether in a queue, or command bus) to be separate as an alternative to self-handling jobs.
I have explained the purpose of this fix (and discussed it in detail) with Taylor, but I'll explain it here for the benefit of those reviewing.
Having the separation between commands and handlers makes the most sense in 'multi-app' environments that use a single queue consumer project. Consider the following:
Consider the following job:
Apps 1-3 might wish to fire this job, but to do so they will need to import the package for
FooServiceusing composer, even though it's never used from those projects.By separating the command and handler (splitting into two classes, one a value object, the other with a handle method) and allowing the user to map commands to handlers we can fire the jobs from APP1-3 without the FooService requirement.
Mapping commands looks like the following:
Bus::map(CommandClassHere::class, HandlerClassHere::class);Firing jobs should use the 'command':
Stand alone handlers should inject their dependencies through the constructor, where existing self-handling jobs will inject their dependencies through the handle method.
This change should be backwards compatible and still allow for self-handling jobs to function as before.
Thanks for reading!