ごん、お前だったのかタスクベースUIを支えていたのは。

CQRS

CQRS(Command Query Responsibility Segregation, コマンドクエリ責務分離)とは Greg Young さんという方が考えたデザインパターンです。原典はこちら(pdf)から読めます。

CQRSについてはいろいろ意見がありますが、ご本人の記事によると、コマンド(=状態を変更するメソッド)とクエリ(=値を返すメソッド)をもった一つのオブジェクトを、コマンドのみのオブジェクトとクエリのみのオブジェクトに分離しようというだけのパターンです。

以下は上記リンクの擬似コード例です。

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

このクラスをもとにして、以下の２つのクラスに分割するのがCQRSパターンです。

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

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

CQRSというパターン自体は基本的にはここまでで、先の本人記事にあるとおり、アーキテクチャでもなければストレージの読み書きとも無関係である。ただ、このように状態の変更を伴う操作と値を返却する操作が一つだったものをそれぞれ分割することだけを指す。

さて、ここまではとても単純な話です。というか、もともとバートランド・メイヤーが言っているCQSとそんなに変わらないみたいなのですが、グレッグさんはこのパターンになかなか深い洞察を持っています。

いったいUIとなんの関係が...？という前に、CQRSを考える前提をおさらいしましょう。

CRUD UI

グレッグ・ヤングさんがCQRSを引き合いにだして批判する対象がCRUD UIです。CRUDとは、Create, Read, Update, Deleteの頭文字をとったものですが、"同一の対象"にたいする4種類の操作をまとめてCRUDと呼びます¹。
CRUD UIをプログラムに直訳してしまうと、あるオブジェクトに対する状態変更もできるし、同じオブジェクトから値を取得できることになります。データベースのテーブル上の行とプログラムのオブジェクトをマッピングするActiveRecordが近いのではないでしょうか。また、先程の CustomerService は「状態変更と値の読み取り」がセットになったオブジェクトで、CRUD的な思考からでてきたデザインだと、グレッグさんは考えているわけです。

CRUDを批判するに際して、おそらくグレッグさんの念頭にあったのは "REST" API² だと思われます。先程の CustomerService を、一つのエンドポイントにたいして GET/POST/PUT/DELETE していると考えたときに、システムは指示されたとおりに処理をしているだけで、意味を理解していない。そこにあるのはただのデータ操作であり、そういうものは意味を失った「貧血オブジェクト」だというのが、グレッグさんのCRUDに対する主な批判です(そういえば最近サーバーサイドエンジニアはたまにjson返すだけおじさん扱いされたりしますね)。

さて、これがグレッグ的CQRSの前提です。つまりグレッグ的なCQRSとは、CRUDの単一なオブジェクトをコマンドとクエリに分割することです。
そしてようやくタスクベースUIが登場します。

Task-Based UI

グレッグさんのテキストを読むまで知らなかったのですが、タスクベースUIは Microsoft が提案した概念で、別名 Inductive User Interface と呼ばれ、Windows XP などのデザインのベースになったもののようです。グレッグさんのTask-Based UIには2001年の Microsoft の記事にリンクが貼られています。

グレッグさんの記事は Microsoft の記事の要約になっており、なかなか面白いとおもいます。グレッグさんがこのUIパターンに興味をもつ主な視点は、紛れもなく「CRUDベースUIからコマンドの切り出し」にあります。つまり、デザインは以下のようにリファクタリングされます。

これがCRUDパターンのUIです。Inventory Item がなにかわかりませんが、このアイテムをdeactivate(非活性化)するにはステータス列の値を変化させる必要があるUIになっています。

これを以下のように直します。Deactivate がリンクです。

↓deactivate

ここで興味深いのは、ページ分割が行われていることでしょう。パラメータ表示と更新処理が別ページで表現されています(CRUD UIはこれが一体だった)。タスクベースUIの主な手法として、このように明確にページ分割をすることが先の Microsoft のUIガイドラインにも記載されています。

グレッグさんが興味を持っているのは、どうみても「タスク」です。もとの CRUD UI では、アイテムの非活性化は status パラメータを変えることでしたが、タスクベースUIのなかでは deactivate という操作が切り出されています。おわかりかとおもいますが、タスクを実現する手段がコマンドなのです。CQRSは「クエリとコマンドを分離する」と言われますが、グレッグさんの本質的な関心はあきらかにコマンドのほうなのです。CQRSとタスクベースUIは直接の関係はないと言ったあと、グレッグさんはこのようにいいます。

There is however one thing that does really require a task based UI… That is Domain Driven Design.
しかし、タスクベースUIを本当に必要としているものが1つあります。ドメイン駆動設計です。

またでかい言葉でてきちゃったよ...。手を広げすぎてどう収拾つければ...。

いかがでしたか？

いかがでしたか？じゃないんですよ。もう朝の5時です。なぜ深夜からこんなめんどくさそうな話に手を出したのか、自分でもまったく理解できません。お布団に呼ばれている気がするのでまとめさせてください。まとまらないことはわかっているんですけど。

オブジェクト指向UIデザインの一節を思い出してみましょう。

動詞=やることを指向しているという意味で「タスク指向UI」と呼ぶ

グレッグさんの関心事の「コマンド」は、上野さんの考える「タスク」とじつにぴたり一致しているのです。

そして、グレッグさんは「ドメイン駆動設計にはタスクベースUIが必要だ」と言います。
なぜDDDはタスクベースUIを必要とするのか？それは、操作が意味づけられている必要があるからです。言葉を変えるなら、ユーザーは事前に意味づけられた操作の中を動き回らなければならない。まさにグレッグさんはこのように主張します。

The Application Service Layer in Domain Driven Design represents the tasks the system can perform.
ドメイン駆動設計のアプリケーションサービス層は、システムが実行可能なタスクを表します。

グレッグさんにとってDDDは、タスクの集合です。DDD下手するとタスク指向になるよねみたいなことを去年書いたような...。

さて、ややこしい記事を書いた挙げ句、なにもまとまっていないのですが、「ユーザーは事前に意味づけられた操作の中を動き回らなければならない」と書いてみて、最近読んだ記事を思い出したのでした。

排除アートと過防備都市の誕生。不寛容をめぐるアートとデザイン

排除アートの問題は、じつは都市におけるデザインから単一の意味以外排除されていくというトレンドだと思います。ベンチから「座る」という意味以外を排除することが排除アートにおける「デザイン」なのです。

こんなことを以前つぶやいたのでした。

道具というのは人間の行動可能性を規定しているし、この行動可能性のなかで人間は動き回る。デザインは、この行動可能性を拡張させることもできれば制限することもできる。デザイナーは、公園のベンチに仕切りを入れることによってホームレスを排除することができる。

— 天重誠二 (@tenjuu99) November 6, 2020