Matthias Noback is back with another post in a series looking at using a command bus to execute more complex code in somewhat of an isolation from the rest of the application. In this new post he moves on to some of the secondary tasks that happen inside the commands and how those relate to event handling.

In the previous posts we looked at commands and the command bus. Commands are simple objects which express a user's intention to change something. Internally, the command object is handed over to the command bus, which performs the change that has been requested. While it eventually delegates this task to a dedicated command handler, it also takes care of several other things, like wrapping the command execution in a database transaction and protecting the original order of commands.

He gets into some of these secondary tasks inside of the commands themselves - smaller actions that need to be done as a part of the execution of the command as a whole. He points out that it's tempting to do everything inside the command, but that it can lead to maintenance issues down the line. He suggests that the command shouldn't perform these tasks at all. They should be handled by an event system that uses event objects to pass off responsibility for performing actions to other objects (for example, handling the post-signup process once a user is created). He's done some research on some event dispatchers currently available but found them lacking in one way or another. Instead he opted to integrate one into his SimpleBus library (EventBus) to provide an integrated way of handling these secondary events. An example of it in use is also included.