ドメイン駆動設計-論理削除

Question

それで、素晴らしいドメインモデルが構築されました。リポジトリはデータアクセスを処理し、そうでない場合は処理します。削除の理由を記録する必要があることを示す新しい要件が表示されます。これまで、削除は非常に簡単な=＆gtでした。 Entity.Children.Remove（child）。 ORMツールが状態管理を処理していたため、内部変更の追跡は行われていませんでした。ただし、これをどのように処理するかは正確にはわかりません。

1）削除された子コレクションを親エンティティに保持し、nHibernateから変更追跡を引き出して自分で処理できます。

2）??????

Answer 1

OK削除する前に、削除する子を選択して（既にIDが正しいですか？）、削除をテーブルに記録するために使用するエンティティに変換しませんか。エンティティに理由を追加して保存し、削除を続行します。最良の部分は、汎用エンティティ、つまり「auditInfo」を使用できることです。変換の結果のために、トランザクション内でそれを行うことができるため、何かが失敗した場合にすべてをロールバックできます！ OK、多分クレイジーですが創造的ですか？

Answer 2

IInterceptorインターフェースを実装しますそしてonDelete機能をオーバーライドして、必要な情報をエンティティから取得し、削除する前にロガーに送信します（もちろんNHibernateを使用）？

例

Answer 3

特定のエンティティタイプで削除が比較的まれな場合は、エンティティにフラグを追加して、論理的に「削除済み」としてマークします。実際に行を削除するのではなく。アプリケーションは、通常の状況下でこれらのエンティティの非表示を処理する必要があります。

これにより、許容できない数の「古い」が発生する場合行-ワトソンの答えに似たものを提案します。正確な要件に応じて、削除されたデータと余分な「理由」を記録することでおそらく逃げることができます。アプリケーションから直接どこかにフィールド。インターセプターの使用は監査の観点からはより透過的で快適ですが、別の削除ログ（テーブル、データベース、ファイル）の方がおそらく簡単です。