Redux: ReduxとそれはCQRS（および他のもの）との関係

したがって、イベントソーシングは、これまでに遭遇したことがない場合、ドメインで発生するすべてのものを「イベント」として扱い、すべてのイベントを記録し、そのイベントを信頼できる情報源と見なします。 他のすべてのデータは派生状態として表示されるだけであり、イベントを再生することで再生成できるはずです。

ここにはReduxと非常に強い類似性があると思います。 アクションはイベントであり、純粋なレデューサー関数を使用して状態を変更すると、アクションを再生すると同じ状態に戻ることが保証されます。

イベントソーシングとCQRSは密接に関連していますが、どちらか一方を他方なしで実行することは可能です。 （イベントソーシングの主要な支持者全員がその声明に同意するわけではありませんが、それは別の議論です。）

その長所と短所は次のとおりです。CQRSとイベントソーシングの両方から学ぶべき興味深いことがあり、それらはReduxのいくつかのアイデアを明確にするのに役立つ可能性があります。

CQRSの言語は、FluxやReduxの言語よりも明確だと思いますが、それはおそらく好みの問題です。 確かに、「ストア」という言葉は、フラックスの世界では非常に過負荷になっていると思います。

PS少し時間があれば、おもちゃの例を取り上げて、シリアル化可能なアクションを使用するように変換できるかどうかを確認するかもしれません。 それは難しいことではなく、内部のメタプログラミングの黒魔術のいくつかを取り除くのに役立ちます。

+1

CQRS + Event-Sourceに慣れていない方のために、ここに学習のための優れたリソースがあります。
http://cqrs.nu/tutorial/cs/01-design

@notahat 、私はあなたに同意します：

CQRSとイベントソーシングの両方から学ぶべき興味深いことがあります[…]
CQRSの言語は、FluxやReduxの言語よりも明確だと思います[…]

IMHO、CQRS、およびFluxは非常に似ており、用語のみが異なりますが、Event-SourceはまさにReduxDevToolsが実装するものです。

おもちゃのCQRSの例で行っていたことを少し明確にする図を追加しました： https ：

意図的ではないかもしれませんが、reduxの「シングルストア」は、 @ gregoryyoungによるプレゼンテーションを思い出させます。彼は「現在の状態は以前の動作の左折りです」と説明しています。

@gaearon ReduxストアとEventStoreの背後にあるアイデアの間には直接的な相関関係があると思いますか？

いくつかのFlux実装を使用した私の経験では、 actionsは単なる（イベント|シグナル|メッセージ）であることに同意します。 actionという名前は、何か他のこと（何かをすること）を意味するので、悪い選択だと思います。

通常、流動的に何かを行うことは、非同期アクションで発生します。 それらはおそらくコマンドと呼ばれる方が良いでしょう。

これは実用的ではないようですので、締めくくります。

アクションクリエーターは基本的にコマンドです
アクションは基本的にイベントです
Dispatch（）は事実上コマンドバスです
店舗は多かれ少なかれビューの投影です

Flux＆Reduxは、一般的なCQRSパターン/原則のIMO実装です。

以前の議論から、新しい用語の理由はどちらかだと思います。

1. 類似性は後で気づきました
2. 手荷物を持った開発者を既存の実装/知識から思いとどまらせることを避けるため

あなたが言ったように、CQRSの原則はしばしばDDD /イベントソーシングなどと混同されます-これは単純なコアアイデアを損なう可能性があると思います。

@glenjamin for meアクションクリエーターは、コマンドであってはなりません。 フロントエンドに残すので、基本的にコマンドはありません。ユーザーがUIで何らかのアクションを実行する場合、それはむしろイベントである必要があります。

バックエンドの概念は必ずしもフロントエンドの概念に厳密に関連しているとは限りません。バックエンドはユーザーの意図を非同期的に受信し、フロントは同期的に受信するため、実際には常に過去に発生します。

特にredux-sagaを使い始めた場合は、アクションクリエーターはまったく必要ないと思います。 ここでアクションクリエーターを置き換える方法を参照してください： http ：

redux-thunk：

    <div onClick={e => dispatch(actions.loadUserProfile(123)}>Robert</div>

    function loadUserProfile(userId) {
      return dispatch => fetch(`http://data.com/${userId}`)
        .then(res => res.json())
        .then(
          data => dispatch({ type: 'USER_PROFILE_LOADED', data }),
          err => dispatch({ type: 'USER_PROFILE_LOAD_FAILED', err })
        );
    }

redux-saga：

    <div onClick={e => dispatch({ type: 'USER_NAME_CLICKED', 123 })}>Robert</div>

    function* loadUserProfileSaga() {
      while(true) {
        const action = yield take("USER_NAME_CLICKED")
        const userId = action.payload;
        try {
          const userProfile = yield fetch('http://data.com/${userId}')
          yield put({ type: 'USER_PROFILE_LOADED', userProfile })
        } 
        catch(err) {
          yield put({ type: 'USER_PROFILE_LOAD_FAILED', err })
        }
      }
    }

また、ドメイン駆動設計（イベントソーシングを使用したバックエンドでよく使用される）をフロントエンドで使用する方法についても少し説明しました。 https://github.com/rackt/redux/issues/1315#issuecomment-179164091を参照して

こんにちは、これは非常に興味深いトピックだと思います！ 私のプロジェクトでは、react-reduxとthunksを使用してフロントエンドの基本を作成しました。 私は長い間、サーバーでイベントソーシング/ CQRSを使用してデータを処理、処理、最適化することを計画していました。 Reduxを学び、愛する中で、これがサーバー側のコマンドを処理し、クライアントに表示されるチェックポイントを生成するのに最適な環境である可能性が高いことに気付きました。 ストアは、ほとんどの場合、データストアの複雑なキャッシュのようになり、オンデマンドでロードされます。 コマンドが着信すると、redux-sagas（またはサンク）がコマンドを処理し、永続性（チェックポイント）とレデューサーの両方にアクションを送信します。 クライアントは、RT更新を受信した後、この結果を読み取り、それに応じてredux状態を更新します。

誰かがこれについて何か経験がありますか、またはそれに対する推奨事項はありますか？

@tvedtorama同意します
私はredux-boot 、 redux-boot-webserverのようないくつかのプロジェクトに取り組んでおり、例として、 ReduxAPIに基づいてバックエンドモジュールを構築する方法を示す

ねえ、バックエンドにReduxを使用したい場合は、Reduxは概念的にわずか70locの非常に小さなライブラリであり、Reduxの概念は主に既存のバックエンドストリーム処理システムから着想を得ていることを忘れないでください。

生のReduxをバックエンドに移植する代わりに、ほとんどのツール（devtools / react-redux / reselect ...）を使用できず、必要なツールの多くが欠落しています（ログの永続性、状態のインデックス作成、スナップショット、永続化されたログ） replay）、これらの既存の70locを再利用するために、Reduxが最初に存在する前でも問題を解決した既存のバックエンドツールを活用してみませんか？

私は、 EventStoreのような非常に単純なツールを考えています。これにより、分散イベントログを長期間保持し、ログプロジェクション（Reduxアクションリデューサーと同等）を構築できます。 射影は新しいイベントを発することができるので、それはまた物語のように振る舞うことができます。

より高度なユースケースについては、Kafka、Samza、Stormなどの多くのツールもすでに存在します...

ほとんどの場合、イベントを使用してアプリをモデル化するだけでは不十分である可能性があるため、ドメイン駆動設計として見ることを忘れないでください。おそらく、制限付きコンテキストとは何か、および集約ルートも理解する必要があります。

実際にdevtoolsをソケット経由でバックエンドで使用できることを追加するだけで、ここに例があります。

素晴らしい@zalmoxisus :)

しかし、それがバックエンドに非常に役立つかどうかはわかりません。納得するには、実際の使用法を確認するのを待つ必要があります：p。 イベントソースのアプリを作成する人は通常、レデューサー/プロジェクションの変更後にログ全体を再生します。私の意見では、ユーザーがタイムトラベルを使用する可能性は低くなります。 最終的には、バグのコンテキストを再現するために特定の状態をリセットするのに役立つ可能性がありますが、それはとにかくスナップショットが提供するものです:)

@slorber素晴らしいフィードバックをありがとう！ あなたが言及したサーバーを対象としたツールを調べます。 ただし、フロントエンドとサーバーの両方で同じフレームワークを使用できることは、ツールスタックの学習曲線が少なくなるため、それ自体が利点になる可能性があると思います。 レイヤー間でレデューサーの一部を再利用したいと思っています。 DDDの問題も確かに有効な懸念事項であり、フロントエンドの構造を単にコピーしないように注意する必要があります。 私は、ストア内の並列構造を単に定義することによって、または完全に異なるサガ/レデューサーを持つ並列ストアのいずれかによって、制限されたコンテキストを処理することを考えていました。 これらの並列構造は、同じイベントに部分的に応答しますが、状態の計算方法は異なります。

@ sebas5384非常に興味深いプロジェクトです。時間が許せば、もっと深く調べてみます。

@notahatどうもありがとうございました！ どこかに作成したその図の別のコピーがありますか？ そのリンクは死んでいるようです。