This can take on many forms, the simplest having command messages differ from query messages. It might seem obvious when stated like this, but I guarantee you have violated this idea numerous times. I know I have. For instance, take the example below of a client utilizing a service for a customer.

The example above has 2 interesting characteristics. First, we are sending the entire customer object back to update a single field in the address. This isn’t necessarily bad, but it brings me to the second observation.

When looking through the history of a customer, the ability to tell why the street was changed (if at all) is impossible to discern. The business intent of the change is missing. Did the customer move? Was there a typo in the street? These are very different intentions that mean very different things. Take for instance a business which sends letters when a customer moves confirming receipt of the change. The above snippet of code only allows us to send a letter when the address has changed.

While the above code may be a little more verbose, the intent is clear and the business can act accordingly. Perhaps the business could disallow the move of a customer from Arizona (AZ) to Arkansas (AR) while still allowing a typo correcting an address that was supposed to be in Arkansas but was input incorrectly as Arizona.

In addition to business intent being important in the present, it is also important in the past. The ability to reflect over historical events can prove an invaluable asset to a business. In my next post, I’d like to discuss the Event Sourcing pattern.