A quick introductory sample – Part 1

I want to write a series of posts which describe in detail how we do things in my company. What architecture do we use, which patterns do we follow, and more specifically, how do we implement those features. I invite you to join me on this journey…

Note: the core ideas follow the various examples of Greg Young, Rinat Abdullin, et al.

It all start with a simple picture

A similar image was used by Greg Young in his 6-hour video about DDD, CQRS and Event Sourcing. This image nicely shows us what is happening in an application following CQRS. The client sends commands to the domain (-model). The domain either accepts a command and hence sends ACK (=acknowledged) or refuses it altogether and sends a NACK (not acknowledged) back to the client. If the domain model accepts a command then it produces an event as a result of the execution of the command. The event is consumed by the read model. The read model in turn is used by the client to get its data in the form of DTOs.

Lets write some code to demonstrate how we do things. I will start from scratch, that is from a blank solution, and incrementally develop the  code we need to fulfill the requirements.

But first we have to give a somewhat realistic user story to start with:

As a principal investigator I want to schedule a new task. The task has a group of animals as targets upon which the executor of the task acts. The task is addressed to a group of crew members from whom one can chose to execute the task…

Evidently a user (= the principal investigator) wants to schedule a new task. This is done by the system by sending a command (ScheduleNewTask) to the domain. After discussion with the domain expert it is clear that the command should look like this

The name of the command gives us the context. From it it is clear what the intent is. The command name should thus be unambiguous.

The command is a DTO and its payload usually contains the minimal data necessary to successfully fulfill the request. In our case these are