• 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もDispatcherもシングルトンなサービスとして存在しているので（後述）、インスタンスの管理などの問題が軽減される

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

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

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

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

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