複数のユースケースを実行、全体の出力をレスポンス化。
APIアクセス中心になるので、もういい。
組み合わせの方針 † 
リクエストするときは混乱しないように
仕組みではなくリクエストの作り方で気を付ける。
リクエストを決めるのはリンク。その中からユーザーが選択する。
1つのリンクに複数のユースケース名。実行したい順に書き連ねる。
入出力を分ける †
入力（クエリー）にはユースケース別の接頭辞を付けておく。
同じユースケースを複数回呼ぶことも可能。入力もそれぞれ別に用意できる。
まったく同じ名前のクエリー変数はリスト化して、先頭に近いほうから順にそれぞれ1つのユースケースで使用する（ようにユースケースを作る）。
仕組みを用意するわけではないので、各ユースケースでは自分の接頭辞が付いた変数だけを消費するように。
出力は所定のバッファーに。Dictionary.
いくつか名前があっていいが、レスポンスになるのは1つの決まった名前のバッファーだけ。
それ以外は出力付きユースケースの中でレスポンスに埋め込むように出力ユースケースを作る。
例えばメッセージ表示用の枠に埋め込み。
入力は1つのクエリー→全ユースケース
出力←1つの出力ユースケース←残りのユースケース
使い道 †
編集ぐらいでしか使わないかも。
編集後に利用者設定次第で編集ビューだったり閲覧ビューだったり。
下位展開と同じやり方で †
下位展開ビューは枠だけの物。枠内はそれぞれ別のリクエスト。ブログパーツだらけのページのような物。
それと同じように複数のリクエストを自動発行するようなページを1つ作ればいい。
クライアントは先に返ってきたレスポンスから順次表示できるし好都合。
もういい †
複数のユースケースを一度に呼ぶとレスポンスも一度に返ってくる…ように見えるビュー。
下位展開と同種でいい。「複数のリクエストをサーバーに送る」ためのビューを返すだけ。
→ APIアクセスと、それを行なうビューを返すだけのリクエストに分けるので、もういい。ユースケース間でデータ共有すべきでもないので、やるなら「やることを選べるユースケース」を作るべき。