0

アプリでイベント ソーシングを使用しており、多くのオブジェクトへの変更を開始したユーザーを追跡する必要があります。現在、このようなコードがあります

class Order { 
  setNameBy(newname, User user) {
    applyChange(new OrderRenamed(user.id, newname));
  }
  :
}

私たちのメソッドのほとんどはこのようなものであり、それらはすべてこのように呼び出されます

setNameBy("a new name", SessionContext.currentUser)

ドメインオブジェクト内の SessionContext へのアクセスを検討しています。すなわち:

setNameBy(newname, User user) {
  applyChange(new OrderRenamed(user.id, newname));
}

になる

setName(newname) {
  applyChange(new OrderRenamed(SessionContext.currenUser.id, newname));
}

個人的には、後者のメソッド シグネチャの方がより自然に見えるので好みです。一方、Domain オブジェクト内の SessionContext にアクセスするのは少し面倒に感じます。

では、DDD/CQRS アプリでこのようなセッション データを処理するにはどうすればよいでしょうか? ドメイン オブジェクトの SessionContext にアクセスしても問題ありませんか、それともイベント エンリッチメントなどの他の方法を使用して、ドメインから発行されたイベントにこの情報を追加する必要がありますか?

4

2 に答える 2

2

変更を開始したユーザーの追跡が頻繁に行われる場合、SessionContextはソリューションの固有の部分になるため、IMOは最も抵抗の少ないパスになります（十分なソリューション）。おそらく、UserContextを言い換えると、「ダーティ」なテクニカルカップリングのように聞こえなくなりますか？:)

私は自分のアプリケーションでスレッドにバインドされたコンテキストをよく使用します（イベントソースとそうでないものの両方）。SessionContextがスレッドにバインドされていない場合にSessionContext.currentUserが例外をスローすると、テスト中にバグを見つけるのにも役立ちます（少なくとも私にとってはそうです）。

別の方法として、イベントをユーザー追跡が必要なものとしてマークし（インターフェースを使用するなど）、後でイベントを強化することもできます。これは私にとって少し厄介なことであり、ユーザー情報を必要とするビジネス関数の外部でバインドされていないSessionContext例外が発生するため、問題解決が難しくなる可能性があります。

どちらのソリューションもIMOで十分なソリューションであるため、ほとんどの場合、SessionContextへの結合をどこに配置するかが問題になります。

于 2012-04-11T06:11:39.093 に答える
2

私は、ドメイン モデルが外部の詳細を完全に無視することを好みます。ドメイン オブジェクトでビジネス ルールを適用するためにユーザー ID が必要な場合は、現在のアプローチを使用して、User を引数として送信します。追跡/監査目的でユーザー ID のみが必要な場合は、イベントを充実させることができます。

于 2012-04-11T04:59:52.340 に答える