SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

IDDD本から理解するドメイン駆動設計

実践DDD本 第4章「アーキテクチャ」 ~レイヤからヘキサゴナルへ~

IDDD本から理解するドメイン駆動設計 第4回


  • X ポスト
  • このエントリーをはてなブックマークに追加

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

 イベント駆動アーキテクチャ(EDA:Event Driven Architecture)とは、イベントを待機し、起こったイベントに応じて処理を行うプログラムスタイルです。SaaSOvationでは、ユーザーに待ちが発生したり、タイムアウトが発生したりするような、長いタスクへの対策としてイベント駆動アーキテクチャを導入しました。ヘキサゴナルアーキテクチャの場合、複数ドメイン間で連携を行うような分散処理に適しています。

複数ヘキサゴナルシステムにおけるイベント連携イメージ
複数ヘキサゴナルシステムにおけるイベント連携イメージ

 システムが複数存在する場合、イベントを使うことで複数のシステム間の結合を切り離すことができます。例えば、あるシステムの変更をドメインイベントとして、他システムのイベントサブスクライバに連携することができます。

電話番号一覧から条件一致する件数を探すサンプル

 IDDD本では、イベント駆動に関するアーキテクチャーについて「パイプ&フィルター」「長期プロセス(サーガ)」「イベントソーシング」の3つを紹介しています。まずは「パイプ&フィルター」と「長期プロセス(サーガ)」について紹介します。

 サンプルとして、電話番号の一覧が書かれたテキストファイルから、フリーダイヤルの件数を出力する処理をイベント駆動のイメージで考えてみましょう。UNIXコマンドでは「$cat 電話番号.txt | grep 0120- | uc -l」で実現されます。下図では、この処理を「パイプ&フィルター」方式で表現しています。また、電話番号リスト全体の件数算出を並行して行う例を「長期プロセス(サーガ)」方式にて表現しています。

「パイプ&フィルター」と「長期プロセス」
「パイプ&フィルター」と「長期プロセス」

パイプ&フィルターによるパイプライン

 イベント駆動のシンプルな形が「パイプ&フィルター」といわれるスタイルとなります。上図では、電話番号が記載されたリストがイベントとして渡り、それぞれの処理でフィルターしたり件数を数えたりしていることがわかると思います。

 「パイプ」は土管の流れで、次に渡す「イベント」を表しています。「フィルター」は受信したイベントに応じて単一のタスクを実行するコンポーネントです。このパイプとフィルターを組み合わせることでパイプラインを構築します。

 複数の処理を1つのプログラムで書いてしまうと再利用やチューニングが困難ですが、パイプ&フィルター方式では、コンポーネント単位で再利用したり、ボトルネック部分のリソースを増強したりできるメリットがあります。

長期プロセス(サーガ)による並列パイプライン

 パイプ&フィルターでは、ひとつのパイプラインを対象としていましたが、処理速度の向上のため、複数パイプラインを並列実行したい場合があります。このようなケースでは「長期プロセス(サーガ)」方式を用いることで、並列にパイプラインを制御できます。

 長期プロセスは、柔軟性が高く並列実行もできるアーキテクチャーのため、他システムやレガシーシステムとの統合といった高度な連携時に採用可能です。ただし、長期プロセス方式では、各パイプラインの状態制御に注意を払う必要があります。例えば、インフラやアプリケーションの障害からの復旧、能動的/受動的タイムアウトの管理、重複イベントのメッセージ管理といった制御が必要になります。正常なユースケースだけではなく、失敗を想定したワークフローも組み込む必要があるため、難易度は高くなります。

イベントを記録して再現できるイベントソーシング

 SaaSOvationチームは、政府からの監査対応のためにイベントソーシングを導入しました。このような履歴管理のような要件には「イベントソーシング(Event Sourcing)」というパターンを使用できます。これは、GitやSubversionといったピンポイントで過去の状態に復元できるリビジョン管理ツールの概念に似ています。

イベントソーシングの流れ
イベントソーシングの流れ

 イベントソーシングの流れは、上図の通り、発生したすべてのイベントを「イベントストア」に格納する点が特徴です。記録されたイベントを最初から順番に再生することでオブジェクトの状態を復元できるため、監査やバグ調査において力を発揮します。またイベントストアを使って、データパッチを追加することも可能です。状態が変化した理由や経緯が記録されるというメリットはありますが、モデリングや実装において少なからず影響を与えるため、ビジネス的なメリットが必要な場合に採用を検討してみると良いでしょう。なお、IDDD本の付録Aでは、CQRSとイベントソーシングと組み合わせた実装例を紹介しています。

データファブリック(グリッドベース分散キャッシュ)

 最後に、イベント駆動アーキテクチャの基盤例として、データファブリック(グリッドベース分散キャッシュ)について紹介します。これは一般的な技術というよりは、Pivotal社のGemFireOracle社のCoherenceといった特定の製品で提供されている概念となります。この仕組みには次のような特徴があります。

  • ドメインオブジェクトを永続化してキャッシュに保存
  • マルチレプリケーションにより性能面での管理が容易
  • イベント駆動における送信保証のサポート
  • キャッシュ変更時のプッシュ通知(ビューの即時変更)
  • 長期プロセスのような分散並行処理の管理

 実装時にこれらの要件が必要になった場合は、この機能についても調査してみると良いでしょう。

最後に

 以上、本稿ではDDDと関連あるアーキテクチャについて紹介してきました。DDDではアーキテクチャの制約はありませんが、多くの選択肢があることが理解できたと思います。本稿で紹介したパターンについては、参考資料やクラウドデザインパターンといった書籍にも目を通してみると理解が深まるのではないでしょうか。次の第5回ではDDDの「エンティティ」について紹介します。

参考資料

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
IDDD本から理解するドメイン駆動設計連載記事一覧

もっと読む

この記事の著者

WINGSプロジェクト 青木 淳夫(アオキ アツオ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書記事多数。 RSS Twitter: @yyamada(公式)、@yyamada/wings(メンバーリスト) Facebook

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/9922 2018/11/13 12:50

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング