Skip to content
This repository has been archived by the owner on Feb 20, 2021. It is now read-only.

Glos commands

Jump to bottom
Christopher Bennage edited this page Jan 30, 2015 · 1 revision

Commands

  • Commands are imperatives (e.g. BookSeats); they are requests for the system to perform a task or action. For example, "book two places on conference X" or "allocate speaker Y to room Z."
  • The goal of a Command is to mutate the state of an application in some way to a new, different state.
  • Typically, commands result in an Events being raised.
  • Commands are usually processed just once, by a single recipient.
  • Commands are one-way and can be delivered asynchronously.
  • Commands can be created by a client (for example the UI), and dispatched by a Command handler to the correct Aggregate in the domain.
  • Commands can be created by a Saga, and dispatched by a Command handler to the correct Aggregate in the domain.
  • Can an aggregate create and send a command?
  • Is a command a DTO?
  • A valid command which, for some reason does not result in a mutated state should produce either one of two things: a) raise an appropriate Event - e.g. BookingFailedDueToNoCapacity. Non-Event Store systems would take a similar flow dictated by business requirements), or b) signal creation/create a different command representing an alternative business process flow that handles the specific condition encountered with the command. NB: this raises the point of how a command should specify its alternate processes

Comments about failure and commands

_I think that in MOST circumstances (if not all), the command should succeed (and that makes the async story WAY easier and practical). You can validate against the read model before submitting a command, and this way being almost certain that it will succeed.

  • Julian Dominguez_

_When a user issues a Command, it’ll give the best user experience if it rarely fails. However, from an architectural/implementation point of view, Commands will fail once in a while, and the application should be able to handle that.

  • Mark Seeman_

_True, a race condition can (and will) happen between the read model check and the command handling in an async system.
But it doesn’t necessarly mean that the command will fail. It will just have a different output.
At amazon, if you request a product that is not available any more, they’ll send you a mail to say that the delay will be longer than expected, and that you may cancel the command.   But it will not be a failure, it will be specific business handling.

Clone this wiki locally