APIの分類とか記述とか
当然に、メイヤー先生のQuery/Commandスタイルを採用するのだ。が、CommandよりOperationのほうが好きなので、Query/Operationスタイル。
[追記]以下、非同期に関して混乱した記述があるが、まー、いいや（ママ）。それと、APIのアクセス制御の問題があるが、それはまた。[/追記]
- Query APIは、状態とか状態から計算される量を取得するAPIであり副作用は一切ない。
- 問い合わせ結果は通常、関数の戻り値で返す。が、遅れがある場合はメッセージで非同期に返すかもしれない。
- Operation APIは、状態の変更を要求する。戻り値はvoidだが、失敗や例外を通知する必要があるかも知れない。このときも、通知は遅れる可能性がある。
他にイベントがある。イベントは戻り値も例外もなく、単に送るだけ。
- Query -- 常に twoway（go and back, request and reply/response）
- oneway Operation -- requestのみで、結果は知らん。または、結果は後から非同期で来る。
- Operation -- 成功失敗や例外が戻り値で同期的に返ってくる。
- Event -- 常にoneway
なんらかのリクエストに対して、後から返る（かもしれない）通知はeventではあるが、区別して呼んだほうがいいかもしれない。notificationかな。あと、Eventとoneway Operationの区別も微妙だなー。
それはともかく、Query, Operation, Eventがあると、その使い方が問題になる。使い方を規定するのがプロトコル。プロトコルとは、Query, Operation, Eventの発行（issue）と、それに伴う状態遷移（正確に言えば、内部状態ではなくて、観測者が想定する抽象状態、以前僕はステージと呼んでいたやつ）の時系列を記述したもの。図で描くならシーケンス図みたいなものを使うかな。
プロトコルの記述に遷移生成系（トランスデューサ）が使えたりする。
