イベント駆動設計の戦略
イベントに対して、どのように振る舞うのかを規定したもの
一連の状態で構成されており、そのいずれかが現在の状態となる
それぞれの状態について、その状態にとって意味を持つ一連のイベントがある
それぞれのイベント毎に、システムが遷移する次の状態が定義されている
Observerパターン
Observableと呼ばれるイベント発生源と、そのイベントに関連づけられたobserverと呼ばれるクライアントのリストを管理する 大抵の場合は、observerは指定されたobservableに向けて、呼び出してほしい関数への参照を引き渡す
イベントが発生した場合、observableは、observerのリストに登録された関数を順番に呼び出す
observerはobservableに登録しなければならないが、それは結合を導入することになる
加えて、コールバックの典型的な実装では、observableの処理と同じスレッド内でコールバックが逐次的に処理されることになるため、同期が発生し、パフォーマンス上のボトルネックが生み出される Observerパターンの問題は、Publish/Subscribeという戦略で解決できる
Observerパターンを一般化すると同時に、結合とパフォーマンスの問題を解決してくれる
用意されたパブリッシャーとサブスクライバーは、チャンネルを介して接続される
チャンネルは、ライブラリやプロセス、分散インフラなど、コード本体から切り離されたかたちで実装される
Observerパターンとは異なり、パブリッシャーとサブスクライバー間の通信は、コード以外のところで潜在的かつ非同期に取り扱われる
ほとんどのクラウドサービスプロバイダーは、pubsub機能を用意しており、また、一般的な言語には、pubsubライブラリが用意されているため、それを活用することが賢明
pubsubは非同期イベントの取り扱いを分離する優れたテクノロジーであるものの、過度に使用しているシステムでは、何が起こっているのかを見極めにくいという短所があることには留意しておく
pubsubは、基本的に単なるメッセージパッシングシステムでしかなく、イベントの組み合わせに応答できるシステムを作るためには、イベント処理に時間軸を追加する必要がある
リアクティブプログラミングとストリーム、イベント
リアクティブプログラミングの例としては、スプレッドシートのセル中に他のセルを参照する式が含まれている場合、参照先のセルを更新するとその式が保持しているセルの内容も更新されるというもの
イベントがコード中の反応を引き起こすことを実現しやすくするために、ストリームが重要になる
ストリームを用いることで、イベントをデータのコレクションとして扱えるようになる
ストリームを他のコレクションと同じように扱えることで、操作や結合、フィルタリングなど、データに対して適用できるすべてのことが可能になる
イベントストリームと一般的なコレクションを結合するといったことも可能になる
ストリームは非同期にできるため、到来したイベントに即座に反応するようなコードを記述できる
結果のストリームは、それぞれのストリームから1つずつ要素を取得しながら生成される
イベントはそこら中にあるが、その源が何であれ、イベントを中心にしたコードは、直列的に処理をしていくコードよりもよりレスポンシブで、より分離したものになる