Thomas Pierrain氏がある資産管理会社と新たなプロジェクトを始めた時、重要な要件のひとつとして、現時点で見ると疑問のある判断を下した理由を理解するために、時間を遡ることを可能にする、というものがあった。アムステルダムで先日開催されたDDD Europe 2018でPierrain氏は、時間軸的な課題を持ってイベントソースシステムを構築した自らの経験について論じた。
その会社は、ビジネス関連の情報を全社に提供可能なシステムを構築したいと考えていた。その詳細要件の中に、過去の特定のデータを含んだレポートを生成する機能や、遡及的なイベントを追加して過去を変更する機能、未来のイベントをスケジュールする機能などが含まれていた。
42skillzのコンサルタントであるPierrain氏と同僚は、当初、ビジネスのニーズを把握しかねていたため、何度もミーティングやワークショップを繰り返して、問題領域と要件、およびその真の意味を理解しようとした。過去の記録を変える理由は、何かが起きていた事を後になって見つけ出したような場合に、遡及的(retrospective)にイベントを追加して世界観を変えなければならないからだ。未来のイベントをスケジュールする機能が必要なのは、同社が将来的に起きる事をずっと前から認識していながら、それを見逃した経験があったため、そのような事態を避けたいという考えからだった。
イベントソーシングをベースとしたシステムが適しているとPierrain氏は考えたが、過去の変更やイベントのスケジュールといった機能が疑問に思えた。そこで氏は、イベントソーシングのコミュニティに質問を投げたところ、Greg Young氏を含む何人かの回答が、氏の考えに賛同を示していた。Young氏は、2014年に自身の書いたブログ記事“Event Sourcing and Post/Pre Dated Transactions”についても言及している。
過去のイベントを扱うためには、ニーズに応じた３つのプロジェクションモードが利用可能である。
- 特定の日付の結果を示す“as at”
- 特定の日付に加えて、遡及的に適用されるべき事後のイベントも考慮した“as of”
- 特定の日付に加えて、遡及的に適用されるべきイベントを特定の日付まで考慮した“as of until”
遡及的イベントには、発生日付(実際の日付)と記録日付という2つの日付がある。過去のレポートを作成するには、この2つの日付を考慮しなければならない。このニーズに対して、氏は2つの用語を使用する。
- Viewpoint Date - 特定の時刻における状態を、“as of until”を使用して表現する
- Projection Date - レポートの日付
これはつまり、2017年6月1日にレポートを作成する場合、それが2017年7月1日の世界観に基づくものであれば、2017年6月1日の発生日付を持ち、2017年7月1日までに記録されたイベントを対象とする、ということだ。例として、特定の日付に口座に追加された金額を表すMoneyAddedイベントで説明しよう。過去の日付を使用してレポートを作成する場合、次のようなロジックが使用される。
- 発生日付と記録日付が6月1日であるイベントは追加する。
- 発生日付と記録日付が6月2日であるイベントは追加しない。
- 発生日付が6月1日で記録日付が7月1日であるイベントは追加する。
- 発生日付が6月1日で記録日付が7月2日であるイベントは追加しない。
収縮可能なイベントを作るためにチームは、イベントを生成するコマンドを使用することを決めた。ビジネスロジックを適用する必要があるためだ - ただしユースケースによっては、直接イベントを生成した方が適切な場合もあるとPierrain氏は述べている。未来のイベントに関しては、イベントを生成するコマンドの実行をスケジュールしておくことで解決した。
2015年にはMartin Fowler氏が、Pierrain氏の説明と同じようなタイプの問題を表現する時間的パターン(Temporal pattern)についての記事を書いている。
DDD Europe 2019の計画が開始されたが、詳細な情報はまだ決定していない。
この記事を評価
- 編集者評
- 編集長アクション