イベントソーシングのアイデアは新しいものではない。SQL登場以前のメインフレームでは，一般的にこの方法でシステムを構築していたし，データベースも内部的にはイベントソーシングで動作していた - Greg Young氏は，先日のプレゼンテーションでこのような説明をした。
アルゴリズム取引に従事し，Event Storeのリードアーキテクトであり，CQRSという用語の生みの親でもある氏は，規制対象産業ではごく一般的である，正確性を証明可能な監査ログを備えた確定的システムの必要性を認識していた。このことから氏は，あるアイデアを思い付いたのだ。
状態遷移は，私たちの問題空間における重要部分であり，私たちのドメインでモデル化されるべきものです。
イベントを用いたこのモデリング方法によって，ドメイン内の多くの問題が解決すると考える氏は，財務や金融，あるいは保険などの業界では"現在の状態"という概念を誰も用いていないことを指摘する。このような動作をする理由は，発生した事象のすべてを保持する必要があるからだ - イベントは更新や削除されることのない，不変(immutable)な存在なのである。エラーが発生した場合にはリバース，すなわち元のイベントをキャンセルした後に，改めて正しいイベントを生成して適用する。同時に氏は，現在の状況がどのような形式であっても，それが一過性で，すべてイベントによって得られるものである限り，同じ方法を適用することが可能であるという点を強調する。
氏によれば，開発者の目から見たイベントソーシングのメリットは２つある。
- イベントは不変であるため，スケールアップが非常に容易なモデルである。キャッシュやコピー，共有しても何ら問題はない。
- スモークテストとは，システムが実際に稼働するときの動作を保証するために，実際の使用状況をシミュレートする一連のテストである。すべてのコマンドを保存することにより，処理されたすべてのコマンドを再実行して，予想される変化に関して以前の実行結果と比較することが可能となるため，期待されるシステム動作について，非常に高度な信頼性を得ることができる。
全体として氏は，追加のみで不変というイベントソーシングに関して，多くのビジネスにおいて優れたトランザクションモデルだと考えている。ただし問題は，特定の名前のユーザをすべて検出するというようなクエリが，SQLデータベースで常にテーブルのフルスキャンを行わなければならないような，非常に厄介なものになる可能性がある点だ。これは読み込みから書き込みを分離して，そのようなクエリでは別途最適化した読み込みモデルを使用するという，CQRSが面白くなってくる部分でもある。あるいはドキュメントデータベースとOLAPキューブのように，さまざまなクエリ用に複数の読み込みモデルを用意するような方法もありそうだ。
氏は次のように結論付けている。
レポート，検索，トランザクション動作に，ひとつのモデルを適用することはできません ...