Command Design Pattern

Encapsulates a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations¹. It also serves to decouple the implementation of the request from the requestor².

Notes

• On previous projects I’ve worked on, this approach created some problems because of the way it was implemented and used. Some problems I remember are:
  • Most (if not all) commands were expected to return something.
  • Controllers were calling services which, inside, were dispatching commands which were calling other services, and so on. The whole flow was hard to understand and to follow.
  • Command handlers did not support throwing events when the operation was done, thus adding behavior on command completion was not supported, and required coupling the actual command to all these other behaviors.

Open Questions

• Under which circumstances is it acceptable to expect a return value from commands, and under which circumstances is it not? I know, for example, that Brighter supports certain uses cases where you can mutate the command itself to communicate something back to the caller (e.g. a creation API which needs to return the newly-created resource).