One of the most powerful features of the CQS Architecture is the ability to create highly expressive tests.
When a set of commands are executed on an aggregate root the expected result is one or more events.
Before you execute your commands you must get your aggregate root in the required state, in other words you need to set up the context of the test. Loading an aggregate root into the required state is done by replaying a set of events.
Do you see the power of this way of testing ? You can express your test only using events and commands ! Yes. It deserves an exclamation mark. A specification/test would look something like this:
Given
UserCreatedEvent {Name=”Greggy”, Age=12, Address=”Bergen”}
When
ChangeUserNameCommand{Name=”Greg”}
Then
UserNameChangeEvent{Name=”Greg”}
OK, I’ll admit to the fact that this wasn’t a very good example :) Ignoring that, I’m hoping you see the power of writing tests this way. Look at how the language of the events in the past tense and the commands in the imperative form goes together with the “Given-When-Then” paradigm. It’s beautiful how things just fit together using BDD and DDD this way. Of course you would expect that from two so similar abbreviations. In case your were wondering, it was Greg who pointed this out :)
Creating the specifications this way fits well in with DDD idea of the ubiquitous language. You are really getting closer to the BDD dream of having your business people writing your specifications. Sweet.
Should I give some code examples perhaps?
Edit:
In the post I omitted the fact that it’s the command handlers in front of the aggregate root that is actually getting the commands and mapping them to behaviors in the aggregate root. It won’t change the post that much, but it’s important information.
