私は会議オブジェクトを持っています:
Meeting{id, name, time, CreatedBy, UpdatedBy}
そして
MeetingAssignee{id, MeetingID, EmployeeId, CreatedBy, UpdatedBy)
Meeting は Aggregate ルートとして、メソッド AssignEmployee を持っています。
AssignEmployee を呼び出すときに現在のユーザーを Meeting オブジェクトに渡そうとしていたので、それに応じて監査フィールドを更新できます。
しかし、これは正しくないようです。明らかに、監査フィールドを公開しておき、後で変更することができます-おそらくサービスレベルで?
これらのフィールドを更新するために誰もが好む他の方法は何ですか?
注: 私たちは Nhibernate を使用していませんが、自動化されていないカスタム ORM を使用しています。
ありがとう。
ドメインイベントの使用を検討してください。
ドメインモデルで興味深いものはすべて、起こったことを声に出して叫ぶイベントを発生させるはずです。外部から、dbまたは他の場所にそれらをダンプするログハンドラーをアタッチするだけです。
そうすれば、ドメインをある種のIAuditServiceで混乱させる必要はありません。
さらに良い-ドメインモデルは、それ自体の内部で通信する方法としてイベントを使用できます。
それが良い考えである理由を示すために、朝、日の出、花のドメインモデルを説明していることを視覚化してください。
すべての花に開花するように伝えるのは太陽の責任ですか？あまり。太陽は（イベントを発生させるために）十分に明るく輝く必要があり、光は地球に降りて行き（イベントを可能にする何らかのインフラストラクチャが必要です）、花は光を受け取ったときに反応する必要があります（他のドメインモデルはイベントを処理する必要があります）。
別の例え-信号機の色を確認するのはドライバーの責任です。
監査とロギングは、通常、アプリケーションのあらゆる場所で必要であり、両方とも要件であるため、楽しいものです（ロギングは、OP担当者からの要件です）。
モデルの多くを知らなくても、監査が要件である必要があるため、現在のユーザーをに渡し、AssignEmployeeそこに「MeetingUpdatedまたはAssigneeAdded ...」という行を追加する代わりにAuditBlahBlahBlah、イベントを追加します。良い名前）そしてそのイベントは監査を行うクラスにディスパッチされます。このように、Meetingクラスは監査についての手がかりがなく、監査目的でビジネスイベントをディスパッチします（私の見解では、これは非常にDDDっぽいです）。
他の人が何を言うのだろうか（うまくいけば、私は何か新しいことを学ぶことができます！）
監査機能を必要とするサービスに監査サービスを挿入して、エンティティを永続化または更新するときに、サービス層から監査サービスを呼び出し、新しく作成されたエンティティをできるだけ迅速に永続化することができます。
特にエンティティが永続化される前にシステム内で使用可能なエンティティとして存在する場合は、どのように、いつ監査するかを理解するのがいかに難しいかがわかります。それらが永続化される前にしばらく存在していたとしても、作成の詳細を含むメモリ内監査データを作成し、エンティティが最終的に永続化されるときにそれを永続化することができます。または、作成者、作成者、変更者、変更者などのデータをエンティティ内のプライベート フィールドとして設定し、エンティティが永続化されたときに監査ログに書き込みますか?
トレードオフがどうなるかに興味があります。