はじめに

少し時間が経ってしまいましたが、AWS Dev Day 2023 Tokyo の Day 2 に参加しました。本記事は「E-3: 実践！モノリスからマイクロサービス！Event Storming によるドメイン駆動設計から実装まで」についてのレポートとなります。

内容に関して個人的な解釈を多分に含みますが、記事としての読みやすさの観点から言い切り型になっている点についてご了承ください。

セッション内容

モノリスからマイクロサービスへ移行する道筋について話されていました。以下のような流れです。

  1. なぜマイクロサービスアーキテクチャを採用するのか
  2. マイクロサービスに適した組織
  3. ドメイン分割を導くための Event Storming
  4. 実装に向けた非機能要件への適用
  5. ストラングラーパターンによる移行
  6. ドメインモデルからのインフラストラクチャコードの分離

前提として以下の注釈がありました。

  • 本セッションはマイクロサービスアーキテクチャを推奨するものではない
  • 組織の課題にアーキテクチャがフィットするかどうかが大事

なぜマイクロサービスアーキテクチャを採用するのか

マイクロサービスにリファクタリングする理由として以下が挙げられていました。

  • デプロイの影響範囲を小さくする
  • 機能的な自律性と単一責任の原則
  • 開発速度の向上
  • スケーリングの最適化

これは同日のモダンアプリケーションにおける分散トランザクションの動機と実装でも切り口になっていた「デプロイの独立性」と同じで、最適なデプロイがまず前提としてあって、それがサービスの分割の動機づけになるということだと解釈しました。

マイクロサービスに適した組織

マイクロサービスが良い選択肢にならない組織として以下が紹介されていました。

  • ドメイン (サービス境界) が不明確
  • スタートアップ企業 (マイクロサービスの複雑性が足枷になる)
  • 市販品ソフトウェア
  • 正当な理由がない

マイクロサービスの組織では以下の特色があります。これは適切なデプロイを回すことができる組織という観点と紐づくものです。

  • チームが自律性 (意識決定する権限と責任) を持つ
  • 開発チームが運用も行う
  • Two Pizza Team
  • デプロイで必要なすべてを所有

ではどのようにしてサービスを分割し、マイクロサービス化を進めるかというところで、ドメイン駆動設計が紹介されていました。ドメイン駆動の考え方でマイクロサービスを設計する際のポイントとして以下が挙げられていました。

  • ビジネスドメインを理解する
  • 境界づけられたコンテキスト (Bounded Context) からサブドメインを定義する
  • コンテキストマッピングを定義する

ドメイン分割を導くための Event Storming

ドメイン分割をするための手法として、Event Storming が紹介されていました。これはドメインエキスパートと開発者が協力して実施する、業務の特性から境界づけられたコンテキストとモデルを導き出すためのワークショップで、(そのまま書き出しただけですが) 流れとしては以下となります。

Big Picture

  • Event の洗い出し、時系列化
  • Pivotal Event (分割点になる Event) をマーク
  • スイムレーンの発見 (並行処理、分岐点) の発見
  • 関係者/外部システムの洗い出し
  • ナレーション／ウォークスルー

Process Modeling

  • 洗い出したイベントをつなぎプロセスにする
  • コマンド
  • ロール
  • リードモデル
  • ポリシー
  • システム
  • ホットスポット

Software Design

  • 集約を見つけ、名前をつける
  • 境界づけられたコンテキストを見つける
  • 詳細設計に入り、コーディングできる状態にする

また、データソースの分割も検討しなければならない課題です。モノリシックな DB をそれぞれのサービスに適したデータソースに分割します。境界づけられたコンテキストがそれぞれサブドメインを持ち、その中に複数の集約があり、集約がトランザクションの単位となります。集約同士でデータに関連がある場合の変更の伝播は結果整合となります。

実装に向けた非機能要件への適用

ドメインモデルは概念的なものなので、実装まで到達するためには物理アーキテクチャに変換する必要があります。概念モデル > 論理アーキテクチャ > 物理アーキテクチャという流れです。
非機能要件は論理的なコンポーネント (API ゲートウェイコンポーネント、認証プロバイダコンポーネント、etc) に対して適用します。物理アーキテクチャでは以下が重要とされていました。

  • なぜそのアーキテクチャを選択したか、意思決定を記録する
  • 付加価値を生まない重労働をクラウドサービスにオフロードする
  • デプロイ単位を決定し素早いリリースサイクルを可能にする
  • 可観測性を高める

ストラングラーパターンによる移行

モノリスからマイクロサービスに移行する戦略としてストラングラーパターンが紹介されていました。ビッグバン移行 (一括での移行) はリスクが高く推奨されません。

  • ストラングラーパターン
  • レガシーアプリケーションのさまざまなコンポーネントに対して Event や API を徐々に生やしていき、それらを利用して徐々に移行していくパターン

ドメインモデルからのインフラストラクチャコードの分離

ここまで設計してきたドメインモデルをコードに落とし込みます。ドメインモデルはピュアなビジネスロジックを実装するため、テスト駆動開発と相性がよいと話されていたのが印象的でした。
また、インフラストラクチャをドメインモデルから分離することで、ドメイン層をシステム的な関心ごとから分離することができます。

おわりに

2 つ前の野村さんのセッションと重なる部分が多く、その意味では解像度が少し上がった状態で聴講することができました。
ドメイン分割を実際に行うためのワークショップとして Event Storming なるものがあり、手法として確立されている点が印象的でした。
サービスを分割する動機づけとしてデプロイの独立性が発端となっており、組織が俊敏性やスケーラビリティを持った状態を維持するためにデプロイの考え方が非常に重要という点が学びになりました。