実装していくうちにレイヤやシステムの境界に対する認識が変わってきたので現状を整理。Intentアプリ外部から受け取った入力をアプリ内部で使える語彙・データ形式に変換するためのアダプタ。アプリ外部からの入力を解釈して、アプリに何をしてほしくてそれを入力したのかを判断し、その要求をModelに伝える。「xxxが起こった」という形式ではあまり良くなくて、「xxxしてほしい」という形式になるのがベストという理解をしている。(HTTP経由の入力に反応する例)ModelIntentからの入力をもとに状態の管理を行う。状態は変数に格納するとかではなくて、Observableの中に生き続ける。Elixir/Erlangやったことがある人は、Agentを使って無限ループするプロセスでKVSを表現したりする事例を知っているかもしれないけど、そういう感じに近いです。状態が正規化されていない場合は、状態同士の依存関係などもModelで表現される。記事ID一覧と記事一覧を状態として保持しているとしたら、「記事一覧は記事ID一覧に依存しており、記事ID一覧が変更されるとそれに伴って記事一覧も更新される」といったことがModelで表現されることになる。ViewModelからの入力をもとにアプリ外部へリクエストを返す。対してはpushStateリクエスト、HTTPに対してはHTTPリクエストを送るといったイメージ。DriverDrievrは、アプリ外部とのインターフェースとなるやつ。ビジネスロジックを一切含まない、ので普通はライブラリ化して別のアプリと共有できる。Modelでアプリ外部と通信するのは得策ではない。Intentから「記事を削除してくれ」という入力がきたらModelから記事を削除するHTTPリクエストを送りたくなるだろうが、「HTTPリクエストを送信する要求」をViewに返すのがよい。メリットを理解しにくければ、実際にシステム外部と通信しないほうがテストしやすいということを考えるととりあえず納得しやすい。「HTTPリクエストを送信する要求」をもとに実際にリクエストを送ってレスポンスを受け取るのがDriverの。