背景
モジュラーモノリスの段階からイベントソーシングを取り入れておくことで、
データの正確性などの品質は向上し、安全に必要に応じて、分散化できる一方で、
猛烈な違和感があった。
それは、自分が過去にいた案件では、
ミッションクリティカルなビジネス
という特性があったからだ。
問い
ここで、
「ミッションクリティカルでないビジネスでは、モジュラーモノリスの段階からイベントソーシングを取り入れる必要のあるケースなんてあるのだろうか？」
という疑問が浮かびました。
リソースの限られた環境下では、モジュラーモノリスの段階からイベントソーシングを取り入れることが実質無理なことだってあるはずです。
そこで、今回の最大の問いは、
モジュラーモノリスの段階からイベントソーシングを導入するのと、
マイクロサービス移行時にイベントソーシングを導入するやり方
のどちらがより適しているのか？
です。
1. モジュラーモノリスの初期段階からイベントソーシングを導入
最初から、モノリス内部の各モジュール（コンポーネント）間のやり取りを、イベントソーシングの仕組みで構築するアプローチです。
✅メリット
将来のマイクロサービス化が劇的に容易になる
これが最大のメリット。
各モジュールはすでにイベントを発行・購読しているため、将来サービスを物理的に分割する際には、ネットワークの境界線を引くだけで済みます。
後からイベント発行の仕組みを追加する、最も困難な作業を省略できます。
完全な監査証跡が最初から手に入る
ビジネスが始まった初日から、全ての状態変化がイベントとして記録されます。
これは、将来のデータ分析やデバッグにおいて、計り知れない価値を生みます。
❌デメリット
初期開発の複雑性と速度の低下
イベントソーシングは、従来のCRUD（状態を直接更新する）アプローチに比べて、学習コストが高く、実装もだいぶ複雑です。
これにより、ビジネスの仮説検証を素早く行いたい初期段階（PoC/MVP）での開発スピードが高確率で犠牲になる可能性があります。
オーバーエンジニアリングのリスク
まだ不確実な未来のために、過剰な設計をしてしまうリスクがあります。
仮にもし、その事業がスケールせず、マイクロサービス化が不要になった場合、イベントソーシングの複雑さだけが技術的負債としてのしかかります。
どんな状況に適しているか
・金融や医療、防衛など、厳密な監査証跡がビジネス要件の中核である。
・将来的に大規模なスケールがほぼ確実に見えている。
・チームがイベントソーシングの経験豊富か、学習コストをかける覚悟・お金がある。
2. マイクロサービス移行時にイベントソーシングを導入
まだ事業がヒットしていないようなフェーズでは、シンプルなCRUDのモノリスとして開発し、システムの成長に伴ってマイクロサービス化が必要になった段階で、初めてイベントソーシング（イベントストア）を導入するアプローチです。
こっちの方が世の中では母数的に多いんではないでしょうか。
✅メリット
初期開発のシンプルさと速さ
チームが慣れ親しんだシンプルなデータ永続化手法で開発できるため、迅速にプロダクトを市場に投入し、ビジネス価値を検証することに集中できます。
必要な時に、必要な分だけ複雑さを導入
YAGNIの原則に従い、イベントソーシングという高度なパターンの導入を、それが本当に必要になる（＝マイクロサービス化によるスケールが必要になる）時まで遅らせることができます。
❌デメリット
移行時の技術的難易度が上がる
これが最大の課題。
状態ベースで設計されたモノリスから、後付けで信頼性の高いイベントを発行する仕組み（トランザクショナル・アウトボックスなど）を導入するのは、非常に困難で複雑な作業になります。
初期の履歴データが失われる
モノリスとして稼働していた期間の、詳細な状態変化の履歴はイベントとして残っていません。
後からデータベースの変更ログなどからある程度復元することは可能ですが、完全ではありません。
なので、よくあるのが、イベントそーソングにし始めた時点を起点となるよう目印を付けます。
どんな状況に適しているか
・Time to Market（市場投入の速さ）が最優先されるスタートアップなど。
・ビジネスモデルの不確実性が高く、まずはモノリスで素早く仮説検証を回したい。
多くの場合、特に新規事業においては、不確実性を受け入れて後者の方が、より現実的でリスクの低い選択となることが多いでしょう。
複数の判断軸
実は、以下の３つの判断基準で、ざっくりしたスコアリングをすることができます。
もしもこの３つの軸だけでは曖昧過ぎてスコアリングできないなら、各軸を副特性軸へと分解して、その副特性軸でスコアリングをします。
そのスコアポイントの上で、モジュラーモノリスの段階からイベントソーシングにするか？
それともマイクロサービス移行時にイベントソーシングを導入にするか？を選ぶようにしましょう。
判断基準1：ビジネス要件の性質
A) 最初からイベントソーシングが適しているケース
以下の性質を持つ場合は、初期の複雑さを乗り越えてでも、最初から導入する価値が高いです。
📈 厳密な監査証跡が必須
金融の取引履歴、医療のカルテ更新、保険の契約変更など、
「いつ、誰が、何を、どのように変更したか」という完全な履歴
が、ビジネスの根幹をなす、あるいは法的に要求される場合。
🕰️ 時間軸に関わる機能が重要
「1ヶ月前の顧客の状態を復元して調査したい」「過去の特定の時点のデータでシミュレーションを行いたい」といった、時間軸（Temporal）に関わる機能が、将来の重要なセールスポイントや分析要件になる場合。
B) 後から導入する方が現実的なケース
🚀 市場投入の速さが最優先
ビジネスモデルが未検証で、とにかく早くMVPを市場に出して、顧客のフィードバックを得ることが何よりも重要な場合。
CRUDアプローチの方が開発速度は速く、仮説検証のサイクルを高速に回せます。
📝 監査要件が「現在の状態」で十分
監査要件が、過去の全ての変更履歴ではなく、「現在の最終的な状態が正しいこと」を証明できれば十分な場合。
判断基準2：チームのスキルと経験
A) 最初からイベントソーシングが適しているケース
🧑💻 チームの経験が豊富
チームメンバーの多くが、すでにイベントソーシングやDDDの実践経験を持っているか、
あるいはその学習に非常に強い意欲を持っている場合。
この場合であれば、学習コストは最小限で済みます。
🤔 抽象化が得意な文化
チームが、ビジネスの事象を「イベント」として捉え、抽象的なモデルについて議論することに慣れている、あるいはそれを好む文化がある場合。
B) 後から導入する方が現実的なケース
🏃 チームがCRUDに習熟
チームが、従来の状態ベースのデータベース設計とCRUD操作に深く習熟しており、その開発スタイルで高い生産性を発揮できる場合。慣れた手法でまず価値を生み出すことを優先しましょう。
🤯 新しい概念への抵抗
イベントソーシングは、データの持ち方から考え方まで、従来の設計の常識を覆します。
この新しいパラダイムへの学習コストや心理的な抵抗が大きいと判断される場合、導入を急ぐべきではありません。
判断基準3：将来のアーキテクチャ展望
A) 最初からイベントソーシングが適しているケース
🏙️ マイクロサービス化が明確なロードマップにある
プロジェクトの初期段階から、数年以内に多数の独立したサービス群へと発展することが、
ビジネス戦略の方針として明確に描かれている場合。
初期投資は、将来の移行コストを大幅に削減するための戦略的な布石となります。
B) 後から導入する方が現実的なケース
🏔️ まずはモノリスで成功を目指す
「まずは単一のアプリケーション（モジュラーモノリス）として成功を収め、事業が軌道に乗ってから、スケールが必要になった部分だけを切り出す」という、より現実的で漸進的な成長戦略を描いている場合。
意思決定のための質問リスト
皆さんのプロジェクトにおいて、どちらのアプローチが適しているかを判断するために、
以下の質問に答えてみてください。
我々のビジネスにとって状態の変更の完全な履歴は、単なるログ以上の資産となるか？
チームは、新しい技術パラダイムの学習コストやお金を支払ってでも、将来の拡張性を今すぐ手に入れるべき状況か？
ビジネスの不確実性は、どのくらい高いか？
1年後にこのプロダクトのビジネスモデル構造が全く違う形になっている可能性は？
これらの質問に対する答えが「Yes」に多ければモジュラーモノリスの段階からイベントソーシングを、「No」に多ければ後からイベントソーシングを導入が、より現実的な選択となるでしょう。