イベント駆動アーキテクチャ

📖 もうちょい詳しく

何が新しいの？

これまでのシステムは「Aが終わったらBを呼ぶ」と、処理の順番を一本道で書くことが多くありました。イベント駆動アーキテクチャは、その代わりに「注文が入った」「決済が完了した」といった出来事（イベント）を真ん中に置きます。出来事を起点にして処理がつながるので、機能をあとから足したり外したりしやすくなります。

どうやって動いてるの？

何かが起きた側（送り手）は「こういう出来事がありました」とお知らせを出すだけで、誰がそれを受け取るかは気にしません。受け取りたい側（受け手）は、あらかじめ「この出来事が来たら教えて」と登録しておきます。あいだには、お知らせを一時的にためて順番に配る仕組み（メッセージキューなど）が入ることが多いです。これにより送り手と受け手が直接つながらず、ゆるく結びつきます。

何ができるの？

ネット通販で「注文完了」という出来事が一つ起きると、在庫を減らす処理、メールを送る処理、ポイントを付ける処理が、それぞれ独立して動き出します。一つの処理が遅くても他は待たされにくく、あとから「SNSに通知する」機能を足すのも、新しい受け手を増やすだけで済みます。

🌱 身近なたとえ

会社の館内放送で例えると分かりやすいです。「会議室Aの準備ができました」と放送する人は、誰が聞いているかを一人ずつ確認しません。放送を聞きたい人だけが耳をかたむけ、自分に関係する内容なら動きます。放送する側と聞く側がお互いを知らなくても回るのが、イベント駆動の感覚に近いです。

✅ まず覚えるポイント

• 「出来事（イベント）」をきっかけに処理が動く組み立て方です
• お知らせを出す側（送り手）と受け取る側（受け手）が直接つながりません
• あいだにお知らせをためて配る仕組み（メッセージキュー等）が入ることが多いです
• 機能の追加・削除がしやすく、変更に強い構成になります
• 一つの出来事から複数の処理を、別々に並行して動かせます
• マイクロサービスのように分かれたシステムをつなぐ場面と相性が良いです

🧭 よくある勘違い

処理が速くなる仕組みなの？

速さそのものを保証する技術ではありません。狙いは「部品どうしのつながりをゆるくして、変更や拡張をしやすくする」ことです。結果として待ち時間が減る場合はありますが、設計の目的は柔軟さの方にあります。

出来事を出せば必ずすぐ届くの？

多くの場合、お知らせは一度ためられてから配られます。そのため受け手に届くまでにわずかな遅れが出たり、状態が一時的にそろわないことがあります。即時に結果が必要な処理には、別のやり方を組み合わせることもあります。

🧩 関連して覚えると楽な言葉

• メッセージキュー (message-queue): お知らせを一時的にためて、順番に受け手へ配る通り道です
• Pub/Sub (pub-sub): 出来事を「発行する側」と「受け取る側」を切り離して結ぶ配信のしくみです
• マイクロサービス (microservices): システムを小さな部品に分けて作る方式で、イベントでつなぐと相性が良いです
• Webhook (webhook): 出来事が起きたとき、相手のURLへ自動でお知らせを送るしくみです

🏁 ひとことでまとめ

「これが起きたよ」という合図を中心に、関係する処理が自分から動き出す。そんな、変化に強いシステムの組み立て方です。