5

ですから、私はアプリケーションのCQRSの概念が好きです。これは、主に、イベントソーシングをすでにサポートしているためです（概念的には、そこにある処方箋に従わないでください）。ただし、CQRSはビッグデータ、結果整合性などを対象としているようです。私たちは常にリレーショナルDBアプリになるので、それが適合するかどうかはわかりません。

また、アプリ層で特別なことをする必要があると思うので、心配しています。読み取りを行うときは、セキュリティを強化し、データをフィルタリングする必要があります。これは、従来はアプリケーション層に実装されていたものです。

私の最初の質問は、私のアプリは適合していますか（従来のMVC /リレーショナルDBアプリ）？または、従来のアプリレイヤーを使用してDTOマッパーを使用する方が理にかなっていますか？

私の2番目の質問は、従来のアプリケーション層からドメインモデルにコマンドを発行することは意味がありますか？私はコマンド/コマンドハンドラーとイベントのアイデアが好きです。

私の質問を明確にしましょう。承認に関連するデータフィルタリングについて懸念があります。ユーザーがデータを要求するときは、特定のデータ要素をまとめて削除する（呼び出し元に返されないようにする）、値を非表示にする、またはデータにマスクを適用することにより、特定のデータ要素へのアクセスを制限するフィルターが必要です。不自然な例では、社会保障番号の場合、リクエストを行ったユーザーは最後の4つの番号しか表示できない可能性があるため、結果は###-##-1234のようになります。

私の主張は、この責任はアプリケーション層にあるということです。これは、クエリまたはコマンドへのすべての応答がこのフィルターメカニズムを通過する必要がある側面だと思います。これが私のCQRSの素朴さが際立つところです。おそらく、コマンドがデータを返すことはなく、読み取りモデルで検索されたデータへのポインターだけを返すのでしょうか。

ありがとう！

4

1 に答える 1

10

何よりもまず、CQRSとリレーショナルデータベースはお互いを排除しません。高度なシナリオでは、SQLベースのDBを他のストレージ手段に置き換えることは理にかなっているかもしれませんが、概念としてのCQRSは永続性メカニズムを気にしません。

ロールやユーザーに依存する複数のビューの場合、ThinReadLayerはおそらく複数の結果セットを提供する必要があります。

  1. その情報へのアクセスを許可されているユーザーの完全なSSNを含むもの。
  2. その情報を表示することを許可されていないユーザーのための別のもの
  3. ..。

これらは別のデータストアに保存できますが、単一のSQLベースのデータベースを使用している場合は、SQLビューを介して提供することもできます。

CQRSでは、アプリケーションサービスはコマンドハンドラーの形式で引き続き存在します。これらはネストできます。つまり、最初に承認を処理してから、含まれているコマンドハンドラーにコマンドを送信します。

public class AuthorizationHandler {

    public CrmAuthorizationService(CrmCommandHandler handler) {
        _next = handler;
    }

    public void Handle(SomeCommand c) {
        if (authorized) _next.Handle(c);
    }
}

// Usage:
var handler = new CrmAuthorizationService(new CrmCommandHandler());
bus.Register<SomeCommand>(handler.Handle);

このようにして、ロギング、トランザクションなどのために、たとえばRESTエンベロープとして複数のハンドラーをネストできます。

あなたの質問に答えるには：

まず、CQRSはアプリに適していますか？特定の要件を実際に掘り下げなければ、誰もわかりません。MVCとリレーショナルDBを使用しているからといって、CQRSの長所と短所に関しては何の意味もありません。

2番目：はい。場合によっては、アプリケーション層が従来の方法でクライアントと対話し、認証や承認などを処理してから、内部でコマンドを発行することが理にかなっている場合があります。これは、MVCベースのUIまたはRESTAPIをアプリケーションの上に配置するときに役立ちます。

コメントに応じて更新：

理想的な、純粋なCQRSシナリオでは、Sallyは、すべてのビューに対して独自の非正規化データを持ちます。たとえば、CustomerListForSally、CustomerDetailsForSallyなどと呼ばれるNoSQL DB内のいくつかのドキュメントです。これらには、表示が許可されているものが入力されます。

彼女が昇進すると（これは重要なドメインイベントになります）、非正規化されたすべてのデータは自動的に上書きされ、現在表示できるものを含むように拡張されます。

もちろん、私たちは合理的かつ実用的であり続ける必要がありますが、この理想は私たちが向かっている一般的な方向性でなければなりません。

実際には、おそらくある種のユーザー/役割またはユーザー/グループベースのシステムがあります。機密情報を表示できるようにするには、特定の役割またはグループのメンバーである必要があります。これらのそれぞれは、定義されたビューとコマンドのセットを持つことができます。これは、非正規化されたデータである必要はありません。SQLビューの対応と同じくらい簡単にすることができます。

  • CustomerDetailsForSupportStaff
  • マスクされていないSSNを使用したCustomerDetailsForSupportExecutive
  • CustomerListForSupportStaff
  • CustomerListForSupportExecutiveと顧客の収益の合計
  • 等
于 2012-09-27T15:38:25.393 に答える