"I've been avoiding CQRS for a while, but Greg Young's text has made me very excited. It's like another solution to the same problem as DCI, but I didn't understand it."

Hey, "you" are who was behind the task-based UI.

CQRS

CQRS (Command Query Responsibility Segregation) is a design pattern by Greg Young. You can read the original from here(pdf).

There are many opinions about CQRS, but you can read his article According to his article, the pattern is to separate an object with a command (= method to change the state) and a query (= method to return a value) into a command-only object and a query-only object.

The following is a pseudo-code example of the above link.

void MakeCustomerPreferred(CustomerId)
Customer GetCustomer(CustomerId)
CustomerSet GetCustomersWithName(Name)
CustomerSet GetPreferredCustomers()
void ChangeCustomerLocale(CustomerId, NewLocale)
void CreateCustomer(Customer)
void EditCustomerDetails(CustomerDetails)

Based on this class, the CQRS pattern splits it into the following two classes.

void MakeCustomerPreferred(CustomerId)
void ChangeCustomerLocale(CustomerId, NewLocale)
void CreateCustomer(Customer)
void EditCustomerDetails(CustomerDetails)

Customer GetCustomer(CustomerId)
CustomerSet GetCustomersWithName(Name)
CustomerSet GetPreferredCustomers()

The CQRS pattern itself basically ends here, and as mentioned earlier in his article, it is not architectural or storage read/write related. It just means splitting up what used to be one operation that changed the state and one that returned a value.

Now, so far, it's very simple. So far it's pretty simple, it's not that different from Bertrand Mayer's CQS, but Greg has some great insights into this pattern.

What does this have to do with UI? Before we get into that, let's review some of the assumptions behind CQRS.

CRUD UI

The subject of Greg Young's critique of CQRS is CRUD UI, an acronym for Create, Read, Update, Delete, which collectively refers to four different operations on the "same object"¹.
The CRUD UI translates directly into a program, which means that you can change the state of an object and retrieve a value from the same object. This is similar to ActiveRecord, which maps rows in a database table to objects in a program. Also, the CustomerService object is a combination of "state change and value read", which Greg thinks is a CRUD-like design.

In criticising CRUD, it was probably the "REST" API² that Greg had in mind. If you think of the CustomerService as a GET/POST/PUT/DELETE to a single endpoint, the system is just doing what it's told, it doesn't know what it's doing. Greg's main criticism of CRUD is that what's there is just data manipulation, and that such things are "anaemic objects" that have lost their meaning (come to think of it, recently server-side engineers are sometimes treated as uncles for returning json).

Now, this is the premise of greg's CQRS. In other words, greg-like CQRS is about splitting the single object of CRUD into commands and queries.
Finally, the Task-Based UI comes into play.

Task-Based UI

I didn't know this until I read Greg's text, but Task-Based UI is a concept proposed by Microsoft, also known as Inductive User Interface, and it seems to be the basis for the design of Windows XP and others. Greg's Task-Based UI has a Microsoft article from 2001 previous-versions/ms997506(v=msdn.10)?redirectedfrom=MSDN).

Greg's article is a summary of the Microsoft article, which I find quite interesting. Greg's main interest in this UI pattern is undoubtedly the "carving out of commands from CRUD-based UI" perspective. In other words, the design is refactored to look like this

This is the UI of the CRUD pattern: I don't know what Inventory Item is, but it's the UI where you need to change the value of the status column to deactivate the item.

Fix this as follows. The Deactivate is the link.

↓deactivate

What is interesting here is the pagination that has taken place. The parameter display and the update process are represented on separate pages (the CRUD UI was one and the same). This clear pagination as the main technique for task-based UI is also described in the earlier Microsoft UI guidelines.

What Greg is interested in is, for all intents and purposes, "Task". In the original CRUD UI, deactivating an item was a matter of changing the status parameter, but in the task-based UI, the operation deactivate has been carved out. As you can see, commands are the means by which tasks are realized, and while CQRS is said to "separate queries from commands", Greg's main interest is clearly in commands. There is however one thing that does.

There is however one thing that does really require a task based UI... That is ".

Another big word "DDD"....

Did you like it?

How did you like it? It's not. It's already 5 in the morning. I don't understand at all why I started such a troublesome story at midnight. I feel like the futon is calling me, so let me summarise. I know it's hard to summarize.

Let me remind you of a passage from Object Oriented UI Design.

We call it "task-oriented UI" in the sense that verbs = oriented to do.

Greg's concern about "commands" is exactly the same as Ueno's concern about "tasks".

And Greg says, "Task-based UI is necessary for Domain Driven Design.
Why does DDD need a task-based UI? It's because operation needs to be meaningful. In other words, users need to be able to move around in a pre-defined set of operations. This is exactly what greg argues.

The Application Service Layer in Domain Driven Design represents the tasks the system can perform.
The Application Service Layer in Domain Driven Design represents the tasks the system can perform.

For Greg, DDD is a set of tasks.

Now, after writing a complicated article, I don't have anything coherent, but when I wrote "the user has to move around in a pre-assigned operation", I remembered an article I read recently.

Exclusionary Art and the Birth of the Overprotected City. Art and Design on Intolerance

I think the problem of exclusionary art is really a trend towards the exclusion of any single meaning from urban design. The exclusion of anything other than the meaning of "sitting" from the bench is the "design" of exclusion art.

This is what I tweeted before.

Tools define the possibility of human action, and in this possibility we move around. Design can either extend or restrict this possibility of action. Designers can exclude the homeless by putting partitions in park benches.

— Seiji Tenjuu (@tenjuu99) November 6, 2020