In this section, we are going to design a part of the reference domain using the tools we have learned in this chapter.

Our team is getting together again to discuss part of the system in more details. They have decided that the classified ad life cycle is their core domain at the first stage and that the section related to additional services and payments will be implemented later due to their investor's decision to gain users before monetizing the application.

First thing first and we need to quickly review the events that are identified to take part of the classified ad life cycle. Our team gets to work from a space but quickly reaches the point where they get this on the wall:

As you can see, this model is a little bit different from the final model from the previous chapter. Every time the team gets to discuss the model, some changes occur because team members get a better understanding of the domain.

The next thing they do is putting some commands that result in events that are already present on the model. In many cases, commands demonstrate the direct intent of users to do something that directly results in events. Such commands are the most obvious ones and come to the model first.

Sometime later the model looked like this:

The team then agrees that most commands are executed by users but then the discussion sparks about who the user is. Technically, everyone who uses the system is a user. But different people can do different things, and something that is allowed to be done by administrators cannot be done by regular users. It is obvious, but from there the team identified the need to separate people by what they do. Of course, one person can always play different roles, but in this concrete example, most operations are done by one type of users - those who want to sell things. Naturally, the role was identified as Seller. After making this discovery, the model started to get more details:

As you can see, along the way more roles were identified and assigned to commands. For example, an ad cannot be approved or rejected by the seller; this makes no sense. Someone from inside the service needs to do this work and either allow the ad to be published or deny publication for one or another reason.

Interesting enough, since the discussed context is only covering the ad life cycle, there is no buyer involved. So, the team keeps interchangeably using the word, owner, and seller. For the sake of consistency, they lean towards using the term seller but remember that all words in the Ubiquitous Language are context-specific. And the reason why we do not have the buyer here is that, up to the current team understanding, they will only deal with buyers in some other parts of the system, meaning another context. Preliminarily, they identified that buyers would participate in conversations about buying agreements and terms, and in the escrow context, should this be required. Also, the team keeps thinking about mutual reviews and naturally both sellers and buyers will be participating in such an activity.

Then, thoughts start to roam around events that can appear for different reasons. One of those events is Ad deactivated. It might happen when the Seller clicks in Deactivate button when looking at the ad, or when the ad was rejected for publication by the Reviewer. The discovery is made that the Deactivate Ad command can be executed by both the Seller, and by the system itself when a policy to deactivate rejected ads is triggered. Putting policies to the model resulted in some more details:

Finally, the team went through some commands that required specific information to be displayed to allow users to make decisions and execute them as commands. Not everywhere such clarity can be reached during the first iteration, and in such cases, the team needs to postpone making any decisions for the later stage. It is more important to make progress and move on than chase too granular model, which will never be perfect anyway.

For example, when adding a category to the ad, sellers must be able to choose from the list of existing categories using some advanced techniques like type-ahead search. And for reviewers, it is helpful not only to see the ad content but also get more details about the seller, who authored the ad. A combination of factors like the seller experience on the platform, the number of previously published ads, number of currently published ads and finally the current ad content - all these factors can bring clarity for reviewers, helping to distinguish malicious ads from legitimate ones.

When working with read-models, there is a lot of opportunities for developers to work together with UX experts, UI designers, and other people, since real models are natural parts of the user interface. But commands should not be forgotten too since they are those handlers that make the system to do something useful. Without commands, the whole system would be just a collection of static pages since there would be n way to change the system state and execute any behavior. The entire user interface of any system is a collection of read-models with command executors attached to them as buttons and other action-triggering elements.

You might also think about task-based UI, a useful approach to design user interface elements in such a way that leads users to make simple, atomic and precise operations. In our example, we used task-based UI too because our sellers change the ad price separately from the ad title simply because these operations are substantially different. The idea of task-based UI comes very much aligned with CQRS and command handling. No surprise, the most information about this technique can be found in old Greg Young's articles related to CQRS, like this article: https://cqrs.wordpress.com/documents/task-based-ui/.