レポート目的でのイベントのロギング
レポートおよびBIシステムで使用するイベントのロギングに関する設計パターンまたはベストプラクティスはありますか？.
たとえば、Webサイトからの注文を管理するシステムでは、顧客サポート担当者が注文番号を入力して、注文が特定の日に行われ、特定の日に発送され、別の日に配送されたことを確認できれば有益です。
これを回避する方法は2つあります。フィールドを持つ注文オブジェクトがあります：
OrderDate
DespatchDate
DeliveryDate
それらが発生した場合はそれらを入力し、そうでない場合はnullになります
OR
次のようなメッセージのようなイベントのログを記録します。
Order Number - "12312312" - Ordered on '2014/01/01'
Order Number - "12312312" - Despatched on '2014/01/01'
イベントをデータベースに追加して追加します。
これに関するガイドラインはありますか？たとえば、TFSの作業項目履歴はどのように機能しますか？
ロバートは彼の答えで良い指摘をしました。
さらに、Martin Fowler here （および、より一般的には Temporal Patterns ）によって記述されているように、監査ログを確認することもできます。これらのイベントのビジネスアクティビティの監視/ビジネスレポートだけではなく、イベントソーシングを確認することもできます。 Fowlerが紹介 here を提供します。
これらの用語を使用して、ウェブ上の他の意見を検索できます。
これが生成されて誰かに渡される実際のビジネス関連レポートである場合は、データベースにイベントレコードを生成し、それらのレコードからレポートを作成します。単にメッセージを添付するのではなく、レコードに実際の意味の意味を与えます。つまり、彼らを一流の市民にするのです。
ロギングは別の目的に役立ちます。ロギングは、ビジネスロジックメカニズムではなく、システム監視ツールとして意図されています。レポートがビジネスの運営に不可欠な部分である場合は、アプリケーションの不可欠な部分にします。