Reading the result of your command with the Command Pattern

Question

I am currently looking into developing a new system utilizing hexagonal architecture and the commandpattern facilitated by a commandbus like tactician (it's a PHP system).

Now I really like the idea of the commandpattern but what I don't get yet is how to get back the actual result of what the command has done.

Lets say I issue a RegisterPatient command with the following fields:

• Name
• Address
• Birthdate

etc

The command has been filled with data from say a HTTP interface, given to the commandhandler and executed. If everything goes alright it will create a Patient object and persist it to the database. But the commandpattern does not let me return the constructed Patient object, in part because there is the possibility of adding middleware before and after, so it should return the command itself.

I get that there is a value in separating read from write applications but in practice, how do I get the data from the datastore after the command has been executed or read queries in general? Would it be unwise to inject the RepositoryInterface for a certain model directly into my controller if I wanted to generate an index view for instance?

What are practical ways to handle errors with commands?

Help much appreciated.

Answer 1

My question has been answered in this article: http://php-and-symfony.matthiasnoback.nl/2015/01/some-questions-about-the-command-bus/

The command bus has no return value. So instead of waiting for the ID to come back from the database, the ID should be one of the values of the command object. If you then hand it over to the command bus, and nothing fails, you can safely assume that an entity with the given ID has been created (usually an ID is a UUID, instead of an auto-incremented ID from the database).

Answer 2

In this example of the command pattern, returning a value is handled with a callback. I would imagine that a future or promise would work just as well.

Decoupling of the return type is not mentioned in the example; in systems I've seen that are similar to this where you subscribe to an Event (the moral equivalent of a "generic" callback), one would return a bare object, and then cast it to the expected return type.

Handling errors would be a simple matter of providing an error code or condition in the returned object.