Task-Based UI and CQRS

これは作者の@amashigeseiji氏の了解を得て、日本語の記事を英語にしたものです。


* Original text (ja): https://qiita.com/amashigeseiji/items/3ad45bc08d15ecf7b0a7
* Translated with www.DeepL.com/Translator (free version)

# Task-Based UI?

The term "task-based UI" has recently become famous, I think, because Mr. Ueno mentions it a lot.

Here is a quote from "Object Oriented UI Design".
> An operating model designed with objects as its starting point, such as GUI, is called "object-oriented UI", whereas an operating model designed with verbs as its starting point, such as CLI, is called "task-oriented UI" in the sense that verbs = things to do.

It is also written in this way.

> It could be said that much of modern design has developed in a task-oriented vector. That is, to view design narrowly as an immediate resolution procedure for a manifest problem.

What Mr. Ueno means by "task-oriented" design is problem-solving oriented design, which is normal, as he points out that much of contemporary design has developed in a task-oriented manner (you've probably heard the saying "design is problem-solving", right?) ). (Have you ever heard the phrase "design is problem solving"?) It's a uniquely ideological term in the Ueno language, and is used in a critical context.

I thought the term "Task-Oriented UI" was coined by Mr. Ueno, but when I read the [CQRS text](https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf), I found __[Task-Based UI](https://cqrs.wordpress.com/documents/task-based-ui/)__, I was surprised to find a chapter about it.

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">I've been avoiding CQRS for a while, but Greg Young's text really got me excited. I'm not sure if it's the same as DCI, but I didn't understand it. </p>&mdash; Seiji Tenju (@tenjuu99) <a href="https://twitter.com/tenjuu99/status/1322199191674781697?ref_src=twsrc%5Etfw">October 30, 2020</a ></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

"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)](https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf).

There are many opinions about CQRS, but you can read [his article](https://web.archive.org/web/20200828042742/http://codebetter.com/gregyoung/2010/02/16/cqrs-task-) According to [his article]( based-uis-event-sourcing-agh/), 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.

```java:CustomerService
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.

```java:CustomerWriteService
void MakeCustomerPreferred(CustomerId)
void ChangeCustomerLocale(CustomerId, NewLocale)
void CreateCustomer(Customer)
void EditCustomerDetails(CustomerDetails)
```

```java:CustomerReadService
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"[^1].
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.

[^1]: I put this in quotes because I don't understand why CREATE and UPDATE are lumped together as CRUD when they are clearly not operations on the "same object".

In criticising CRUD, it was probably the "REST" API[^2] 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](https://bliki-ja.github.io/AnemicDomainModel/)" that have lost their meaning (come to think of it, recently server-side engineers are sometimes treated as uncles for returning json).

[^2]: Again, I put "REST" in quotes, but it's a common misconception that REST = CRUD. Greg used to criticize REST because he thought it was CRUD, but at some point he started to argue that the correct REST would be CQRS.

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](https://cqrs.wordpress.com/documents/task-based-ui/) has a [Microsoft article from 2001](https://docs.microsoft.com/en-us/) 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.

![image6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54738/6dab7fce-aa84-1910-b743-7caf6e31e04d.png)

Fix this as follows. The `Deactivate` is the link.

![image7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54738/a2b9a88c-5a91-d006-1bef-c38235740a6d.png)
↓deactivate
![image8.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/54738/ecb69be1-1964-8e63-1fd3-3b45fb885ee6.png)

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](https://bijutsutecho.com/magazine/insight/23127)

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.

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">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. </p>&mdash; Seiji Tenjuu (@tenjuu99) <a href="https://twitter.com/tenjuu99/status/1324779148083040256?ref_src=twsrc%5Etfw">November 6, 2020</a ></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

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


I don't believe that Greg's system is directly intolerant, but I do think that in order to prevent DDD and CQRS from leading to sophisticated intolerance, we need to think not only about what we want users to do, but also about how to make it fun for them. It's not just "what do we want users to do?

### PS

This article has been peer-reviewed by Greg Young as "reasonable (except for some glitches in the translation software)".

この記事はGreg Young氏から「（一部翻訳ソフトの不具合の他は）妥当な内容である」との査読を受けています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3940/cc379cd5-0f32-7a6e-ced6-df9378882a3c.png)