はじめてのDDD part4.4 ~イベント駆動アーキテクチャについて~

# はじめに
今回は「イベント駆動アーキテクチャ」について紹介します。アーキテクチャの説明もこれでラストです。頑張っていきましょう。
# イベント駆動アーキテクチャ
イベント駆動アーキテクチャはEDA（Event Driven Architecture）とも呼ばれ、イベントを待機し、起こったイベントに応じて処理を行うプログラムスタイルです。
ユーザーに待機時間が生じたり、タイムアウトが発生したりするような長いタスクへの対策としてこれが導入されることが多いです。ヘキサゴナルアーキテクチャの場合、複数ドメイン間で連携を行うような分散処理に適しています（下図参照）。
![スクリーンショット 2024-11-12 101241.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3817741/3d0dd2fc-d096-a800-b497-470a327bac75.png)

このように、<strong>システムが複数存在する場合、イベントを使うことで複数のシステム間の結合を切り離すことができます。</strong>
イベント駆動に関するアーキテクチャについて、「パイプ＆フィルター」、「長期プロセス（サーガ）」、「イベントソージング」の３つをこれから解説していきます。

### 電話番号一覧から条件一致する件数を探すサンプル
まずは、「パイプ＆フィルター」と「長期プロセス（サーガ）」についてです。
サンプルとして、電話番号の一覧が書かれたテキストファイルから、フリーダイヤルの件数を出力する処理を考えてみましょう。下図では、「パイプ＆フィルター方式」と「長期プロセス」方式でわけてあります。
![スクリーンショット 2024-11-12 101308.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3817741/35afd653-b533-0daf-4796-abd0143eb238.png)

### パイプ＆フィルターによるパイプライン
イベント駆動のシンプルな形が「パイプ＆フィルター」といわれるスタイルです。上図では、電話番号が記載されたものが「イベント」として渡り、それぞれの処理（イベント1,2,3）でフィルターしたり、件数を数えたりしています。
「パイプ」は<strong>土管の流れ</strong>で、次に渡すイベントを表しています。「フィルター」は受信したイベントに応じて単一のタスクを実行するものです。このパイプとフィルターを組み合わせることで「パイプライン」を構築します。
複数の処理を１つのプログラムで書いてしまうと再利用やチューニングが困難ですが、パイプ＆フィルター方式では、コンポーネント単位で再利用したり、ボトルネック部分のリソースを増強したりできるメリットがあります。

:::note info
<strong>コンポーネント</strong>
システムやプログラムの中である機能をもった部品のこと。
<strong>ボトルネック</strong>
システムの中で最も処理が遅い部分や処理の進行を妨げる、いわゆる「一番足を引っ張っている部分」のこと。
:::

### 長期プロセス（サーガ）による並列パイプライン
パイプ＆フィルターでは、１つのパイプラインを対象としていましたが、処理速度の向上のために、複数パイプラインを並列実行したい場合もあります。そのような場合にはこの「長期プロセス（サーガ）」を用います。
この方式は、柔軟性が高いので他のシステムやレガシー（古い）システムとの統合といった高度な連携時に採用可能です。
ただ、この方式では各パイプラインの状態制御が課題になりがちです。具体的には、障害が発生したときの復旧方法や時間がかかりすぎた場合のタイムアウト処理などがあります。これの対策として、問題が発生した場合の流れもあらかじめ考えておく必要があるため、管理が難しくなってしまいます。

### イベントを記録して再現できるイベントソージング
履歴管理のような要件には「イベントソージング」というパターンを使用できます。Gitのような、ピンポイントで過去の状態を復元できる「リビジョン管理ツール」の概念に似ています。
![スクリーンショット 2024-11-12 101332.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3817741/7bf02d96-dcc8-8c7f-ddb2-db1b230a6bf7.png)

イベントソージングの特徴は上で示したように、発生したすべてのイベントを「イベントストア」に格納する点です。記録されたイベントを最初から順番に再生すればオブジェクトの状態を復元することができるので、監査やバグ調査において力を発揮します。また、イベントストアを使ってデータパッチ（後付けのプログラム）を追加することも可能です。

### データファブリック（グリッドベース分散コンピューティング）
最後に、イベント駆動アーキテクチャの基盤例として、データファブリック（グリッドベース分散コンピューティング）について紹介します。これは一般的に用いられる技術というよりは、ある特定の製品で提供される概念です。
その仕組みには次のような特徴があります。
<ol>
<li>ドメインオブジェクト（ドメインモデルを表現したオブジェクト）を永続化してキャッシュに保存（すぐに取り出せるようにするイメージ）
<li>マルチレプリケーション（複製しておくイメージ）により性能面での管理が容易
<li>イベント駆動における送信保証のサポート
<li>キャッシュ変更時の通知（ビューの即時変更）
<li>長期プロセスのような分散並行処理の管理
</ol>
実装時にこれらの要件が必要になった場合はこの機能についても調査してみるとよいでしょう。

# おわりに
今回の記事では、「イベント駆動アーキテクチャ」について紹介し、長かったpart4もこれにて終了です。次回のpart5では「エンティティ」について解説します。
では、最後までお読みいただきありがとうございました。次回もよろしくお願いします。

<strong></strong>
### 参考
[「実践ドメイン駆動設計」から学ぶDDDの実装入門/青木 淳夫](https://www.amazon.co.jp/%E3%80%8C%E5%AE%9F%E8%B7%B5%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E9%A7%86%E5%8B%95%E8%A8%AD%E8%A8%88%E3%80%8D%E3%81%8B%E3%82%89%E5%AD%A6%E3%81%B6DDD%E3%81%AE%E5%AE%9F%E8%A3%85%E5%85%A5%E9%96%80-CodeZine-Digital-First-%E9%9D%92%E6%9C%A8/dp/4798161500/ref=tmm_hrd_swatch_0?_encoding=UTF8&sr=8-1)

[実践DDD本 第4章「アーキテクチャ」 ～レイヤからヘキサゴナルへ～](https://codezine.jp/article/detail/9922)

[「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典/ボトルネック](https://wa3.i-3-i.info/word12812.html)