tetsuharuohzeki · March 6, 2018 04:50 · Dec 22, 2014 · Dec 22, 2014 · Dec 8, 2014 · Dec 8, 2014
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -83,7 +83,7 @@ http://facebook.github.io/flux/docs/overview.html:
 * 何も違いません。ただのobserverパターンです。
 
 ## 何がすごいの？
-* ベストプラクティス的なパターンに名前をつけて共通言語としたところです。
+* __ベストプラクティス的なパターンに名前をつけて共通言語としたところ__です。
 * 概念的に非常に革新的な何かがあるというわけではありません。
 * たぶん「誰もが一度は似たような事をやったことがある」と思うが、従来は個々人がそれぞれ別の言葉で呼んでおり、意思疎通の上で面倒くさかった
 

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -82,6 +82,11 @@ http://facebook.github.io/flux/docs/overview.html:
 ## observerパターンと何が違うの？
 * 何も違いません。ただのobserverパターンです。
 
+## 何がすごいの？
+* ベストプラクティス的なパターンに名前をつけて共通言語としたところです。
+* 概念的に非常に革新的な何かがあるというわけではありません。
+* たぶん「誰もが一度は似たような事をやったことがある」と思うが、従来は個々人がそれぞれ別の言葉で呼んでおり、意思疎通の上で面倒くさかった
+
 ## 外部（サーバー）との入出力はActionに入れるべきかStoreに入れるべきか
 [React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、ActionCreatorは
 

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -66,6 +66,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 3. この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.
 
 ## なぜ通常のMVCでは駄目だったか
+http://facebook.github.io/flux/docs/overview.html:
 > 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.
 
 ## MVCと何が違うの

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -6,6 +6,7 @@
 * [javascript - In Flux architecture, how do you manage Store lifecycle? - Stack Overflow](http://stackoverflow.com/questions/23591325/in-flux-architecture-how-do-you-manage-store-lifecycle)
 * [Flux Chat Example](https://github.com/facebook/flux/tree/master/examples/flux-chat)
 * [React JS › Flux: Actions or ActionCreators](https://groups.google.com/d/topic/reactjs/jBPHH4Q-8Sc/discussion)
+* [Stores and form validation? · Issue #2 · facebook/flux](https://github.com/facebook/flux/issues/2)
 
 ## アーキテクチャ本質
 

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -67,9 +67,18 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 ## なぜ通常のMVCでは駄目だったか
 > 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.
 
+## MVCと何が違うの
+* 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいので[wikipedia日本語版の該当項目](http://ja.wikipedia.org/wiki/Model_View_Controller)とか『[A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80](http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf)』の図とか参考）
+  * Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
+  * View: モデルの処理結果・データ類の表示（UI部分）を受け持つ
+  * Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
+* これを踏まえた上で、observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践にしたものだと認識しています
+  * （GUI）アプリケーションで頻出するドメインに名前を付けた
+  * ドメイン間でのメッセージ（データ）フローの方向性を規定
+  * 各ドメインを表すオブジェクトの作り方を細かく述べた
+
 ## observerパターンと何が違うの？
 * 何も違いません。ただのobserverパターンです。
-* observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践に
 
 ## 外部（サーバー）との入出力はActionに入れるべきかStoreに入れるべきか
 [React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、ActionCreatorは

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -75,6 +75,6 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 [React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、ActionCreatorは
 
 * Actionとして標準的な方法を提供する
-* 日和見的なアクション（optimistic action）とサーバーのレスポンスの結果を調整してグローバルなロールバックなどに対応する
+* 日和見的なアクション（optimistic action）とサーバーのレスポンスの結果を調整し、複数のStoreに対するグローバルなロールバックなどをサポートする
 
 のに使うのがよく、無限スクロールなどのようなケースにStoreがサーバーからデータを取得したい場合は、Store内で完結したところで問題はないということ.
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -64,17 +64,17 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 2. やってきた入力を基にDispatcherのメッセージ発行処理を行い、入力されたデータをStoreに叩き込む.
 3. この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.
 
-#### 外部との入出力はActionに入れるべきかStoreに入れるべきか
-[React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、ActionCreatorを使うのに適切な例は
-
-* Actionとして標準的な方法を提供する
-* 日和見的なアクション（optimistic action）とサーバーのレスポンスの結果を調整してグローバルなロールバックなどに対応する
-
-のに使うのがよく、無限スクロールなどのようなケースで、Storeがサーバーからデータを取得したい場合は、Store内で完結したところで問題はないということ.
-
 ## なぜ通常のMVCでは駄目だったか
 > 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パターンです。
-* observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践に
+* observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践に
+
+## 外部（サーバー）との入出力はActionに入れるべきかStoreに入れるべきか
+[React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、ActionCreatorは
+
+* Actionとして標準的な方法を提供する
+* 日和見的なアクション（optimistic action）とサーバーのレスポンスの結果を調整してグローバルなロールバックなどに対応する
+
+のに使うのがよく、無限スクロールなどのようなケースにStoreがサーバーからデータを取得したい場合は、Store内で完結したところで問題はないということ.
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -64,7 +64,8 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 2. やってきた入力を基にDispatcherのメッセージ発行処理を行い、入力されたデータをStoreに叩き込む.
 3. この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.
 
-[React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、
+#### 外部との入出力はActionに入れるべきかStoreに入れるべきか
+[React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、ActionCreatorを使うのに適切な例は
 
 * Actionとして標準的な方法を提供する
 * 日和見的なアクション（optimistic action）とサーバーのレスポンスの結果を調整してグローバルなロールバックなどに対応する
@@ -76,18 +77,4 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 
 ## observerパターンと何が違うの？
 * 何も違いません。ただのobserverパターンです。
-* observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践にしたものだと認識しています
-  * （GUI）アプリケーションで頻出するドメインに名前を付けた
-  * ドメイン間でのメッセージ（データ）フローの方向性を規定
-  * 各ドメインを表すオブジェクトの作り方を細かく述べた
-
-## MVCと何が違うの
-* 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいので[wikipedia日本語版の該当項目](http://ja.wikipedia.org/wiki/Model_View_Controller)とか『[A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80](http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf)』の図とか参考）
-  * Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
-  * View: モデルの処理結果・データ類の表示（UI部分）を受け持つ
-  * Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
-* これを踏まえた
-
-## 一歩間違えるとActionの領域が大きくなりすぎませんか
-* なると思います.
-* あとキャッシュとかちょっと面倒くさいかも.
+* observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践に
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -5,6 +5,7 @@
 * [Flux Application Architecture | React](http://facebook.github.io/flux/docs/overview.html)
 * [javascript - In Flux architecture, how do you manage Store lifecycle? - Stack Overflow](http://stackoverflow.com/questions/23591325/in-flux-architecture-how-do-you-manage-store-lifecycle)
 * [Flux Chat Example](https://github.com/facebook/flux/tree/master/examples/flux-chat)
+* [React JS › Flux: Actions or ActionCreators](https://groups.google.com/d/topic/reactjs/jBPHH4Q-8Sc/discussion)
 
 ## アーキテクチャ本質
 
@@ -58,11 +59,18 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 * 複数インスタンスを作ってよい
 * 過剰なコンポーネント化は、複雑な状態の保持や、予期せぬActionの呼び出しを発生させるので、開発の複雑性を増加させることに注意
 
-### Action
+### ActionCreators 
 1. Viewに対するユーザー入力やネットワーク経由の入力を待ち受ける
 2. やってきた入力を基にDispatcherのメッセージ発行処理を行い、入力されたデータをStoreに叩き込む.
 3. この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.
 
+[React JS › Flux: Actions or ActionCreatorsにおける、Jing Chenの回答](https://groups.google.com/d/msg/reactjs/jBPHH4Q-8Sc/93LMQIt4RmsJ)によると、
+
+* Actionとして標準的な方法を提供する
+* 日和見的なアクション（optimistic action）とサーバーのレスポンスの結果を調整してグローバルなロールバックなどに対応する
+
+のに使うのがよく、無限スクロールなどのようなケースで、Storeがサーバーからデータを取得したい場合は、Store内で完結したところで問題はないということ.
+
 ## なぜ通常のMVCでは駄目だったか
 > 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.
 

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -43,6 +43,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 
 ### Store
 * データ処理の領域を取り扱う。
+  * が、"Nor are they the same as Backbone's collections"とのこと
 * 内部は完全に隠蔽されている
   * 独自にインスタンスを管理していようがシングルトンだろうが、ビューの状態も含めようが、それはロジックの問題である
   * 状態を持つのであれば、状態の生成と破棄のためのメッセージを追加すれば良い
@@ -59,7 +60,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 
 ### Action
 1. Viewに対するユーザー入力やネットワーク経由の入力を待ち受ける
-2. やってきた入力を基にDispatcherのメッセージ発行処理を行い、生の入力データをStoreに叩き込む.
+2. やってきた入力を基にDispatcherのメッセージ発行処理を行い、入力されたデータをStoreに叩き込む.
 3. この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.
 
 ## なぜ通常のMVCでは駄目だったか
@@ -77,4 +78,8 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
   * Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
   * View: モデルの処理結果・データ類の表示（UI部分）を受け持つ
   * Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
-* これを踏まえた
+* これを踏まえた
+
+## 一歩間違えるとActionの領域が大きくなりすぎませんか
+* なると思います.
+* あとキャッシュとかちょっと面倒くさいかも.
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -58,8 +58,9 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 * 過剰なコンポーネント化は、複雑な状態の保持や、予期せぬActionの呼び出しを発生させるので、開発の複雑性を増加させることに注意
 
 ### Action
-* Dispatcherのメッセージ発行処理をラップして、より具体的な形（メソッド呼び出し）に変える
-* 無くても良い
+1. Viewに対するユーザー入力やネットワーク経由の入力を待ち受ける
+2. やってきた入力を基にDispatcherのメッセージ発行処理を行い、生の入力データをStoreに叩き込む.
+3. この入力とメッセージの発行処理をまとめてラップしてActionとして提供する.
 
 ## なぜ通常のMVCでは駄目だったか
 > 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.
@@ -76,7 +77,4 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
   * Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
   * View: モデルの処理結果・データ類の表示（UI部分）を受け持つ
   * Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
-* これを踏まえた上で、こんなところではないかと
- * Controllerの役割のうち、UI操作に関係する領域（ユーザーの入力への反応）をViewの内部に押し込めた（View-Controller）
- * Model（Store）向けの命令箇所をAction/Dispatcherとして切り出した
- * データの流れる方向を一方向に限定した（ControllerとViewの両方に必要な通知を一カ所に集約できた）
+* これを踏まえた
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -2,7 +2,7 @@
 
 ## 参考資料
 
-* [Flux Application Architecture | React](http://facebook.github.io/react/docs/flux-overview.html)
+* [Flux Application Architecture | React](http://facebook.github.io/flux/docs/overview.html)
 * [javascript - In Flux architecture, how do you manage Store lifecycle? - Stack Overflow](http://stackoverflow.com/questions/23591325/in-flux-architecture-how-do-you-manage-store-lifecycle)
 * [Flux Chat Example](https://github.com/facebook/flux/tree/master/examples/flux-chat)
 

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -74,7 +74,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 ## MVCと何が違うの
 * 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいので[wikipedia日本語版の該当項目](http://ja.wikipedia.org/wiki/Model_View_Controller)とか『[A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80](http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf)』の図とか参考）
   * Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
-  * View: データ類の表示（UI部分）を受け持つ
+  * View: モデルの処理結果・データ類の表示（UI部分）を受け持つ
   * Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
 * これを踏まえた上で、こんなところではないかと
  * Controllerの役割のうち、UI操作に関係する領域（ユーザーの入力への反応）をViewの内部に押し込めた（View-Controller）

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -72,7 +72,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
   * 各ドメインを表すオブジェクトの作り方を細かく述べた
 
 ## MVCと何が違うの
-* 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいので[wikipedia日本語版の該当項目](http://ja.wikipedia.org/wiki/Model_View_Controller)とか『[A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80](http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf)』とか参考）
+* 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいので[wikipedia日本語版の該当項目](http://ja.wikipedia.org/wiki/Model_View_Controller)とか『[A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80](http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf)』の図とか参考）
   * Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
   * View: データ類の表示（UI部分）を受け持つ
   * Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -69,4 +69,14 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 * observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践にしたものだと認識しています
   * （GUI）アプリケーションで頻出するドメインに名前を付けた
   * ドメイン間でのメッセージ（データ）フローの方向性を規定
-  * 各ドメインを表すオブジェクトの作り方を細かく述べた
+  * 各ドメインを表すオブジェクトの作り方を細かく述べた
+
+## MVCと何が違うの
+* 宗教論争をするつもりは無いので、MVCの定義を以下とする（面倒くさいので[wikipedia日本語版の該当項目](http://ja.wikipedia.org/wiki/Model_View_Controller)とか『[A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk -80](http://www.ics.uci.edu/~redmiles/ics227-SQ04/papers/KrasnerPope88.pdf)』とか参考）
+  * Model: ドメインロジックの処理（およびデータの取り扱い）を受け持つ
+  * View: データ類の表示（UI部分）を受け持つ
+  * Controller: ユーザの入力に応じてModelに向けて処理を開始するのを受け持つ
+* これを踏まえた上で、こんなところではないかと
+ * Controllerの役割のうち、UI操作に関係する領域（ユーザーの入力への反応）をViewの内部に押し込めた（View-Controller）
+ * Model（Store）向けの命令箇所をAction/Dispatcherとして切り出した
+ * データの流れる方向を一方向に限定した（ControllerとViewの両方に必要な通知を一カ所に集約できた）
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -62,4 +62,11 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 * 無くても良い
 
 ## なぜ通常のMVCでは駄目だったか
-> 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.
+> 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パターンです。
+* observerパターンの上に、若干の条件を追加して、GUIアプリケーション向き実践にしたものだと認識しています
+  * （GUI）アプリケーションで頻出するドメインに名前を付けた
+  * ドメイン間でのメッセージ（データ）フローの方向性を規定
+  * 各ドメインを表すオブジェクトの作り方を細かく述べた
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -43,7 +43,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 
 ### Store
 * データ処理の領域を取り扱う。
-* 内部的は完全に隠蔽されている
+* 内部は完全に隠蔽されている
   * 独自にインスタンスを管理していようがシングルトンだろうが、ビューの状態も含めようが、それはロジックの問題である
   * 状態を持つのであれば、状態の生成と破棄のためのメッセージを追加すれば良い
 * 表向きにはシングルトンなオブジェクトがひとつ公開されており、それ経由でDispatcherからのメッセージ入力を受け取る

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -37,7 +37,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 ### Dispatcher
 * Storeに向けてメッセージを発行する場合は必ずココを介する
 * シングルトンになる
-* facebook/Fluxでは、`waitFor()`という機能を提供することにより、Store間の処理順序の依存性を解決している
+* [`facebook::Flux::Dispatcher`](https://github.com/facebook/flux)では、`waitFor()`という機能を提供することにより、Store間の処理順序の依存性を解決している
   * これが無い場合、Store間の依存性解決用の細かいメッセージを大量に定義する必要が出てくる
   * 無くても解決できるけど有った方が便利だわな
 

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -22,7 +22,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 ```
 
 ### 設計によって得られるメリット
-* メッセージパッシングの採用により、同時にビューが何個存在しようとも「データが更新された」というメッセージが発行されれば、そのメッセージを購読しているビューが勝手に更新される
+* メッセージパッシングの採用により、同時にビューが何個存在しようとも、Storeから「データが更新された」というメッセージが発行されれば、そのメッセージを購読しているビューが勝手に更新される
   * 煩わしい管理をする必要が無い
 * ドメインの組み合わせに応じて、メッセージの流れる方向を制限することで、データフローが常に一つになる
   * 処理の予測が可能になる

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -21,7 +21,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 +-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+
 ```
 
-## 設計によって得られるメリット
+### 設計によって得られるメリット
 * メッセージパッシングの採用により、同時にビューが何個存在しようとも「データが更新された」というメッセージが発行されれば、そのメッセージを購読しているビューが勝手に更新される
   * 煩わしい管理をする必要が無い
 * ドメインの組み合わせに応じて、メッセージの流れる方向を制限することで、データフローが常に一つになる
@@ -61,5 +61,5 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 * Dispatcherのメッセージ発行処理をラップして、より具体的な形（メソッド呼び出し）に変える
 * 無くても良い
 
-## 通常のMVCではなぜ駄目だったか
+## なぜ通常のMVCでは駄目だったか
 > 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.
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -59,4 +59,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 
 ### Action
 * Dispatcherのメッセージ発行処理をラップして、より具体的な形（メソッド呼び出し）に変える
-* 無くても良い
+* 無くても良い
+
+## 通常のMVCではなぜ駄目だったか
+> 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.
diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -32,7 +32,7 @@ Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores ---
 * StoreもDispatcherもシングルトンなサービスとして存在しているので（後述）、インスタンスの管理などの問題が軽減される
 
 ## 各ドメイン
-* 設計上、こうした方が良い、という点から
+* 設計上、こうした方が良い、という点から、オブジェクトの生成が規定されることになる
 
 ### Dispatcher
 * Storeに向けてメッセージを発行する場合は必ずココを介する

diff --git a/flux-architecture-memo.md b/flux-architecture-memo.md
@@ -0,0 +1,62 @@
+# Fluxアーキテクチャ覚え書き
+
+## 参考資料
+
+* [Flux Application Architecture | React](http://facebook.github.io/react/docs/flux-overview.html)
+* [javascript - In Flux architecture, how do you manage Store lifecycle? - Stack Overflow](http://stackoverflow.com/questions/23591325/in-flux-architecture-how-do-you-manage-store-lifecycle)
+* [Flux Chat Example](https://github.com/facebook/flux/tree/master/examples/flux-chat)
+
+## アーキテクチャ本質
+
+1. ドメインを分割する
+2. ドメイン間のやり取りをメッセージパッシングのような疎結合な機構を用いて以下のように行う
+  * ユーザーの入力がビューに対して発生したことをロジック側に伝える
+  * ロジック処理の結果にデータが変更したことをビューに伝える
+3. 各ドメイン間のメッセージの送信方向は、組み合わせによって常に一つに決定される
+
+```
+Views ---> (actions) ----> Dispatcher ---> (registered callback) ---> Stores -------+
+Ʌ                                                                                   |
+|                                                                                   V
++-- (Controller-Views "change" event handlers) ---- (Stores emit "change" events) --+
+```
+
+## 設計によって得られるメリット
+* メッセージパッシングの採用により、同時にビューが何個存在しようとも「データが更新された」というメッセージが発行されれば、そのメッセージを購読しているビューが勝手に更新される
+  * 煩わしい管理をする必要が無い
+* ドメインの組み合わせに応じて、メッセージの流れる方向を制限することで、データフローが常に一つになる
+  * 処理の予測が可能になる
+  * メッセージパッシングによって引き起こされる、ドメイン間の依存性地獄の回避
+* メッセージパッシングを使用しているので、ドメイン間の連携が強制的に非同期になる
+  * モデルがいくつのスレッドに分割されていようと、どれだけ時間がかかろうと、設計として全く問題なくなる
+* StoreもDispatcherもシングルトンなサービスとして存在しているので（後述）、インスタンスの管理などの問題が軽減される
+
+## 各ドメイン
+* 設計上、こうした方が良い、という点から
+
+### Dispatcher
+* Storeに向けてメッセージを発行する場合は必ずココを介する
+* シングルトンになる
+* facebook/Fluxでは、`waitFor()`という機能を提供することにより、Store間の処理順序の依存性を解決している
+  * これが無い場合、Store間の依存性解決用の細かいメッセージを大量に定義する必要が出てくる
+  * 無くても解決できるけど有った方が便利だわな
+
+### Store
+* データ処理の領域を取り扱う。
+* 内部的は完全に隠蔽されている
+  * 独自にインスタンスを管理していようがシングルトンだろうが、ビューの状態も含めようが、それはロジックの問題である
+  * 状態を持つのであれば、状態の生成と破棄のためのメッセージを追加すれば良い
+* 表向きにはシングルトンなオブジェクトがひとつ公開されており、それ経由でDispatcherからのメッセージ入力を受け取る
+  * ファサードって言っていいんだっけ？
+
+### View (Controller-View)
+* ユーザーからの入力とデータの出力（表示）を取り扱う
+* Storeから発生するメッセージを購読する
+* Storeからの入力に応じて（一意な）データの出力を行う
+  * Facebookの流儀では、ここでReactを用いて描画コストの問題を解消する
+* 複数インスタンスを作ってよい
+* 過剰なコンポーネント化は、複雑な状態の保持や、予期せぬActionの呼び出しを発生させるので、開発の複雑性を増加させることに注意
+
+### Action
+* Dispatcherのメッセージ発行処理をラップして、より具体的な形（メソッド呼び出し）に変える
+* 無くても良い
No results found