five-rules.txt

1. Your application consists of three parts. Information always flows
   "clockwise": clients, write side, read sides. Clients send Commands
   to write side. Write side publishes Events to read sides. Read sides
   reply to Queries for client.

2. The interesting logic is all in the write side, but your design may
   consist *only* of the totality of Commands, Events, and Queries.

3. Each Command or Event has exactly one aggregate that it's acting on,
   identified by unique aggregate ID. There need not be a one-to-one
   correspondence between Commands and Events. Queries need not be tied
   to aggregates.

4. The write side validates a command (and sends back an ACK/NAK to the
   client) based solely on the "state" of the acted-on aggregate. This
   state is the sum total of all events that were ever published for that
   aggregate. (And nothing else.)

5. Every time you think you want to act across several aggregates -- and
   believe me, you will! -- remember that the CQRS solution for this isn't
   transactions, but workflows. Often these are represented as Sagas,
   which are event consumers (like read sides) and command emitters (like
   clients). For any given aggregate, a Saga is in a given state out of
   a predetermined set of states, and events may trigger state changes
   and/or commands from the Saga.