先月のReactive Summit 2017 Conferenceにおいて、Kevin Webber氏がイベントストーミング（Event Storming）、ドメイン駆動設計（Domain Driven Design）、Cloud Nativeなどを利用した、エンタープライズJavaアプリケーションのクラウドへの移行について語った。
彼はまず、エンタープライズソフトウェアは、システムというよりアプリケーションとして少しずつ作られ続けるもので、これには複雑なインテグレーションを含んでいる、というプレゼンテーションから始めた。従来のインフラストラクチャは、雑なフェイルオーバーによるアクティブ/パッシブなもので、アクティブシステムとパッシブシステム間の複雑な状態のレプリケーションをサポートする。
現代のプロジェクトでは、アーキテクトが下さなくてはならない最初のいくつかの決定（「ファーストマイル」）が極めて重要になる。彼は、重要なアーキテクチャ決定と、そのドメイン駆動設計の原則による導き方について語った。イベントストーミングは、重要なステークホルダーを協調環境に集めて、関連するプロセスとそのイベント駆動システムへの落とし込み方を定義する。チームは、すでにビジネスで発生している、最も関心のあるイベントに注目しなくてはならない。
Anti-corruption Layer (ACL) パターンやStranglerパターンといったコンセプトも、レガシーシステムをリアクティブシステムに移行するのに役立つ。
オニオンアーキテクチャ（Onion architecture）はドメイン駆動設計の概念にうまくフィットする。このアーキテクチャのレイヤーは、さまざまなものを実装するのに役立てることができる。
- インフラストラクチャ: このレイヤーを使って、ヘルスチェック、トラッキング、認証などの横断的な要件を実装する。
- API: ルーティングとデータ検証に役立つ。
- Domain: このレイヤーでコンテキスト境界（Bounded Context）管理する
- Core: ここでアグリゲート（Aggregate）を管理する。
Webber氏は、アプリケーションにとってCloud Nativeが何を意味するのか説明した。アプリケーションには、パッケージ化されて動的に管理される、マイクロサービス指向のコンテナが必要だ。
彼はマイクロサービスアーキテクチャについても語った。まずはモノリスモデルから始めて、リファクタリング手法としてマイクロサービスを用いて、システムを複数のマイクロサービスに分割することをチームにすすめた。マイクロサービスモデルは、分散システムだけでなく分散したチームにも役に立つという。
多くのチームは、サービスレベルでのシステムの分割に注目しているが、データレイヤーは結合したままだ。このアーキテクチャだと、データモデルの変更が複数のサービスに影響を与えることになる。
カンファレンス後、彼にインタビューして、Javaアプリケーションのクラウドインフラストラクチャへの移行についてさらに尋ねた。
マイクロサービスにポイントツーポイントの相互作用がある場合、サービスのガバナンスという面でカオスになるだろう、と彼はいう。心に留めておくべき重要なことは、一方のマイクロサービスの変更がもう一方のマイクロサービスに影響を与えるなら、それらは実際には独立しておらず、2つは結合されているべきだということだ。
マイクロサービスの合成はPub/Subモデルで実現できる。Kafkaのようなサーバーを用いてイベントをキューにポストし、CassandraのようなNoSQLデータベースを用いたイベントログストアに格納する。
こうしたトピックについて詳しく知りたければ、O’Reillyから出ているWebber氏のミニブック『Migrating Java to the Cloud』を読んでみよう。
Rate this Article
- Editor Review
- Chief Editor Action