• Flux Application Architecture | React
• javascript - In Flux architecture, how do you manage Store lifecycle? - Stack Overflow
• Flux Chat Example

1. ドメインを分割する
2. ドメイン間のやり取りをメッセージパッシングのような疎結合な機構を用いて以下のように行う

• ユーザーの入力がビューに対して発生したことをロジック側に伝える
• ロジック処理の結果にデータが変更したことをビューに伝える

3. 各ドメイン間のメッセージの送信方向は、組み合わせによって常に一つに決定される

Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores -------+
Ʌ                                                                                   |
|                                                                                   V
+-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+

• メッセージパッシングの採用により、同時にビューが何個存在しようとも、Storeから「データが更新された」というメッセージが発行されれば、そのメッセージを購読しているビューが勝手に更新される
  • 煩わしい管理をする必要が無い
• ドメインの組み合わせに応じて、メッセージの流れる方向を制限することで、データフローが常に一つになる
  • 処理の予測が可能になる
  • メッセージパッシングによって引き起こされる、ドメイン間の依存性地獄の回避
• メッセージパッシングを使用しているので、ドメイン間の連携が強制的に非同期になる
  • モデルがいくつのスレッドに分割されていようと、どれだけ時間がかかろうと、設計として全く問題なくなる
• StoreもDispatcherもシングルトンなサービスとして存在しているので（後述）、インスタンスの管理などの問題が軽減される

• 設計上、こうした方が良い、という点から、オブジェクトの生成が規定されることになる

• Storeに向けてメッセージを発行する場合は必ずココを介する
• シングルトンになる
• facebook::Flux::Dispatcherでは、waitFor()という機能を提供することにより、Store間の処理順序の依存性を解決している
  • これが無い場合、Store間の依存性解決用の細かいメッセージを大量に定義する必要が出てくる
  • 無くても解決できるけど有った方が便利だわな

• データ処理の領域を取り扱う。
• 内部は完全に隠蔽されている
  • 独自にインスタンスを管理していようがシングルトンだろうが、ビューの状態も含めようが、それはロジックの問題である
  • 状態を持つのであれば、状態の生成と破棄のためのメッセージを追加すれば良い
• 表向きにはシングルトンなオブジェクトがひとつ公開されており、それ経由でDispatcherからのメッセージ入力を受け取る
  • ファサードって言っていいんだっけ？

• ユーザーからの入力とデータの出力（表示）を取り扱う
• Storeから発生するメッセージを購読する
• Storeからの入力に応じて（一意な）データの出力を行う
  • Facebookの流儀では、ここでReactを用いて描画コストの問題を解消する
• 複数インスタンスを作ってよい
• 過剰なコンポーネント化は、複雑な状態の保持や、予期せぬActionの呼び出しを発生させるので、開発の複雑性を増加させることに注意

• Dispatcherのメッセージ発行処理をラップして、より具体的な形（メソッド呼び出し）に変える
• 無くても良い

We originally set out to deal correctly with derived data: for example, we wanted to show an unread count for message threads while another view showed a list of threads, with the unread ones highlighted. This was difficult to handle with MVC — marking a single thread as read would update the thread model, and then also need to update the unread count model. These dependencies and cascading updates often occur in a large MVC application, leading to a tangled weave of data flow and unpredictable results.

• 何も違いません。ただのobserverパターンです。
• observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践にしたものだと認識しています
  • （GUI）アプリケーションで頻出するドメインに名前を付けた
  • ドメイン間でのメッセージ（データ）フローの方向性を規定
  • 各ドメインを表すオブジェクトの作り方を細かく述べた

• 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいのでwikipedia日本語版の該当項目とか『A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80』とか参考）
  • Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
  • View: データ類の表示（UI部分）を受け持つ
  • Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
• これを踏まえた上で、こんなところではないかと
• Controllerの役割のうち、UI操作に関係する領域（ユーザーの入力への反応）をViewの内部に押し込めた（View-Controller）
• Model（Store）向けの命令箇所をAction/Dispatcherとして切り出した
• データの流れる方向を一方向に限定した（ControllerとViewの両方に必要な通知を一カ所に集約できた）