全てのシステムがイベントや事実に基づいているわけではない。ある問題空間の実在するイベントはそれ自体で完全な意味を成す。しかし、多くのシステムが代わりにプロセスを渡って流れる情報に注目してしまう。Greg Young氏は先週ロンドンで開催されたDDD Exchange Dayでドキュメントベースのメッセージングと分析について語った。
銀行内部の不動産ローン業務を例に挙げてみよう。誰かの不動産ローン申請はいろんなポジションの人達の手を通して最終的には証券化される。
Greg氏の経験では、一般的にドメインモデルで構造することは簡単である。難しいのは作用をモデルに埋め込むことだ。
これはプロセスを跨るイベントやドキュメントとメッセージングの比較の異なるスタイルであり、これこそがGreg氏の話の焦点だ。
Greg氏の経験では、一般的にドメインモデルで構築するのは簡単である。難しいのは作用をモデルに埋め込むことだ。
業務担当者と作用に関して話すのは、しばしば一番難しい作業になります。
イベントは業務担当者がシステム上で発生する作用についての考慮を強制することへ役に立つ。ドキュメントは異なる観点を提供する。彼らはほとんどの組織では既に持っているか、過去に持っていた災害復旧プランのような紙ベース業務処理プロセスの流れに注目した。もし、あなたがその書類ベースプロセスを調べることから始めたら、より多く業務担当者とうまく付き合う機会を得るのでしょう。
業務担当者なら書類ベースの業務プロセスフローからすぐに理解することができます。
Greg氏の方法はしばしば非常にうまく機能します。事業家にコンピュータのことを忘れさせ、彼らがどのように様式や他のドキュメントを作成し、処理プロセスの流れをつくるのか？このような方法でプロセスを説明するのはシステムが業務を処理する方式を理解するのに役立つだろう。
紙を使って説明するのが有効なわけはビジネスそのものはパソコンがなかった時代にも行われていたからだ。
我々は２つの概念モデルを使えるようになった。一つはイベント、そしてもう一つはドキュメントに基づいている。Greg氏はその２つが排他的ではないと強調する。イベントはドキュメントを含むことができるし、ドキュメントもイベントを含むことができる。ドキュメントに基づくプロセスフローでイベントはたまに発生するが、そのイベントはプロセスフロー上の現在のドキュメントを含むのだ。
独立コンサルタントであるGreg Young氏はCQRSの生みの親とEvent Storeのリードアーキテクトとして知らされている。