📖

re:Invent 2025: GenAIでレガシーアプリをマイクロサービス化する7ステップのモダナイゼーション手法

2025/12/03に公開

AWS

reinvent2025sessio

idea

はじめに

海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！

re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください

📖 re:Invent 2025: AWS re:Invent 2025 - Breaking the legacy barrier: How AI is revolutionizing modernization (MAM402)

この動画では、GenAIを活用してレガシーなモノリシックアプリケーションをマイクロサービスアーキテクチャへモダナイズする7ステップのアプローチが解説されています。Unicorn e-commerce storeという.NET Core 3.1のサンプルアプリケーションを題材に、Kiroを使ったコード分析、AWS Transformによる.NET 8へのフレームワークアップグレード、Domain Driven DesignとEvent Stormingに基づく分解分析、MCPサーバーを活用したアーキテクチャ図の自動生成、そして最終的なマイクロサービスへのリファクタリングまでが実演されます。特に、適切な粒度でのサービス分割を実現するため、ドメインイベント駆動の分解手法と、Miroを使った仮想Event Stormingボードの生成が詳しく紹介されており、AIと建築方法論を組み合わせることでモダナイゼーションを大幅に加速できることが示されています。

※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。

本編

セッション概要とUnicorn Storeアプリケーションの紹介

皆さん、こんばんは。今日は長い一日だったと思いますが、re:Invent が皆さんにとって素晴らしいスタートになっていることを願っています。今回のセッションでは、GenAI を使ってレガシーの壁を破り、モダナイゼーションを加速させる方法についてお話しする、非常にエキサイティングなトピックを取り上げます。私は Anand Bilgaiyan です。Enterprise Transformation の Senior Specialist Partner Solutions Architect を務めており、Shri と一緒にお話しします。

こんばんは、皆さん。私の名前は Sreekumar Nair です。AWS の Migration and Modernization の Senior Specialist Solutions Architect で、シンガポールを拠点としています。Shri、ありがとうございます。では始めましょう。多くのお客様は、デジタルトランスフォーメーションをビジネス成長をサポートするための重要な優先事項と考えています。しかし、レガシー IT アプリケーションとランドスケープがビジネス成長の障壁となっています。これらのレガシーアプリケーションのモダナイゼーションは複雑で、かなりのコストと労力が必要になる場合があります。ここで、アーキテクチャ方法論、ベストプラクティス、そして GenAI の力を組み合わせて、これらのレガシーアプリケーションのモダナイゼーションを加速させる方法を見ていきます。

では、これからの 1 時間の流れについて簡単なアジェンダをご紹介します。モノリシックからマイクロサービスへのユースケースについて説明します。ここではモノリシックをレガシーアプリケーションの代表として、マイクロサービスベースのクラウドネイティブアーキテクチャをターゲット状態として考えます。その後、アーキテクチャ方法論を使用して、これらのレガシーアーキテクチャからモノリシックからマイクロサービスへどのように収束できるかを見ていきます。その後、その変換を加速させるために GenAI をどのように活用できるかを探ります。これは Level 400 セッションなので、このセッションの一部として、異なるモダナイゼーションフェーズに向けた異なるデモをカバーします。

まず、レガシーモノリシックアプリケーションを表す Unicorn e-commerce store というサンプルアプリケーションを紹介します。このセッション全体を通じて、これをより最新化されたアーキテクチャに収束させていき、最終的には Unicorn store アプリケーションのモダナイズされた状態を実現します。では、この標準的な e-commerce モノリシックアプリケーションにはどのようなビジネス機能があるでしょうか。これは標準的な Web ベースの e-commerce アプリケーションで、ユーザーはログインして、異なる unicorn アイテムを検索し、その仕様と価格を確認することができます。ユーザーのニーズに基づいて、これらの unicorn アイテムを選択し、カートに追加し、カートを確認してから、支払いと配送の詳細を提供することができます。

その後、注文を確定できます。これは、私たちが一般的な e-commerce アプリケーションで使用するような標準的なフローです。では、この Unicorn store モノリシックアプリケーションの機能フローを見てみましょう。ユーザーがログインして、製品を検索し始め、その後、ユーザーの要件に基づいてそれらの製品またはアイテムをカートに追加します。その後、支払いを行い、支払い後に注文を確定します。

では、これらの機能は標準的な .NET Core 3.1 フレームワークを使って構築されています。このアプリケーションをレガシーなモノリシックアーキテクチャにしている特性とは何でしょうか？カート、決済、チェックアウト、商品カタログなど、異なるビジネス機能をサポートするさまざまなモジュールを見てみると、これらのモジュールはすべて単一のアプリケーションの一部として構築され、バンドルされています。

モノリシックアーキテクチャの特性と課題

では、ここまでビジネスの観点からこのフローを見てきました。同じアプリケーションとその特性をアーキテクチャの観点からも改めて見直してみましょう。先ほど述べたように、このアプリケーションはカート、商品、決済に関するさまざまなビジネス機能をサポートするさまざまなモジュールで構成されています。これらのモジュールはすべて同じアプリケーションの一部としてバンドルされています。

これらの製品とモジュールはすべて同じアプリケーションの一部としてバンドルされており、ほとんどの場合同じ共通データベースを活用しています。ここで起きていることは、単一のアプリケーションがすべてを行っているということです。すべてのビジネス機能がこのアプリケーションによってサポートされています。ここに多くの隠れた複雑性があります。異なるモジュールはすべて相互に依存しており、暗黙的に互いを参照している可能性があります。これらがこのアプリケーションをモノリシックにしている特性です。

では、このアプリケーションが直面するさまざまな課題を見てみましょう。1つの課題はスケーラビリティに関するものです。Black Friday セールや Cyber Monday セールを実施していて、注文量が2倍から3倍になることを予想しているとしましょう。 Cyber Monday や Black Friday のイベントに対応するために、注文モジュールをスケールしたいと考えています。しかし、実際に起きることは、アプリケーション全体をスケールしてしまうということです。なぜなら、他のすべてのモジュールが単一のアプリケーションの一部としてバンドルされているからです。これは運用上の課題を引き起こし、デプロイメント全体のコストを増加させます。なぜなら、注文モジュールだけをスケールしたいのに、アプリケーション全体をデプロイすることになるからです。

次の課題は、変更に要する時間が長いということで、これはビジネスの俊敏性にも影響を与えます。新しい機能をリリースする必要があるとしましょう。どの機能でも、アプリケーション全体をテストしてから、アプリケーション全体を本番環境にデプロイする必要があります。これにより、全体的な市場投入までの時間が増加します。モノリシックアプリケーションがもたらすもう一つの課題は、アプリケーションのどのモジュールまたはどの部分に問題が発生しても、アプリケーション全体が機能しなくなる可能性があるということです。これはビジネスの継続性に影響を与え、また多くの運用上の課題をもたらし、環境に技術的負債をもたらします。

モダナイゼーションの段階的アプローチとAWS GenAIツールの紹介

モノリシックアプリケーションの課題を理解したところで、モダナイズしたいのであれば、モダナイゼーションは単一のステップではなく、段階的なアプローチです。このレガシーアプリケーションをより現代的で、俊敏で、クラウドネイティブなアーキテクチャに変換するには、慎重な検討が必要です。この特定のアプリケーションの場合、これを変換またはモダナイズする必要があるとしたら、それをより現代的な状態に変換するために考える必要があり、取る必要があるかもしれない異なるフェーズは何でしょうか。まずそれを見てみましょう。

確実に、最初のフェーズまたは最初のステップは、アプリケーション分析を行うことです。このアプリケーション分析は非常に重要です。なぜなら、モダナイゼーションへの最初のステップを踏み出すのに役立つ可能性のあるアプリケーションに関するいくつかの特性を提供してくれるからです。例えば、前のスライドで述べたように、この特定の UnicornStore アプリケーションは .NET Core 3.1 という古いフレームワークで構築されています。最初にすべきことは、アプリケーションの全体的なパフォーマンスとセキュリティ体制を改善することです。そのため、このアプリケーションをフレームワークの最新バージョンに変換する方が良いでしょう。適切なアプリケーション分析を行うことで、そのような洞察を得ることができます。

アプリケーション分析が完了したら、確実にランタイムとフレームワークを変換したいので、パフォーマンスとセキュリティ体制を改善し、モダンなクラウドネイティブアーキテクチャの周辺に新しい機能を導入するという観点からアプリケーションをより良くすることができます。その後、アーキテクチャ的に行った変更、フレームワークアップグレードの観点から、アプリケーションをビルドして検証する必要があります。それが完了したら、分解分析を実行する必要があります。分解分析について、そしてこの分解分析を実行するためのアーキテクチャ上の方法論について、詳しく説明します。

分解分析が完了すると、このモノリシックアプリケーションが変換または分解される可能性のある異なるサービスの特定が提供されます。最後になりますが、適切なサービスを特定したら、このアプリケーションのリファクタリングを開始し、それに応じて新しいアーキテクチャでモダナイズします。これらのすべての異なるフェーズを見て、適切なアーキテクチャを定義し、適切な分解とアプリケーションのリファクタリングを実行します。

レガシーアプリケーションの現代化プロセスにおけるこれらの異なるステップを実行するために、AWS が提供する GenAI ベースの主要な機能を活用していきます。異なるアーキテクチャの方法論と GenAI の機能を使用します。それでは、これらを素早く見ていきましょう。最初のものは Kiro です。これはプロトタイプから本番環境への加速を実現する AI ベースの IDE です。開発者たちはこれまで主にコードコンパニオンや AI ベースの IDE を活用して VIP コーディングを行ってきました。しかし今、私たちはそのフェーズから脱却したいと考えています。VIP コーディングを行う代わりに、品質の高いコードを書き、その後、スペック駆動型ソフトウェア開発アプローチに移行したいのです。このアプローチでは、プロンプトが仕様書になります。これにより、適切なビジネス分析と要件分析を実施し、その後、要件に応じてアプリケーションを設計し、それらの要件を実装し、最終的にそのコードを実行することができます。ソフトウェア構築のライフサイクル全体が、Kiro という AI 駆動型 IDE によって支援されます。

Kiro にはさまざまな機能があります。最初の機能は、先ほど説明したスペック駆動型ソフトウェア開発アプローチを使用して新しいアプリケーションを構築するのに役立つということです。既存のアプリケーションを変更することもできます。ビジネス要件に基づいて新しい変更リクエストを採用する必要がある場合です。そして最後になりますが、既存のアプリケーションコードベースのリファクタリングと現代化もサポートしています。このセッションを通じて、現代化のさまざまなフェーズに進むにつれて、この特定の機能に焦点を当てていきます。

次に、このセッションで取り上げる非常に重要で主要なサービスは AWS Transform です。これは大規模な移行と現代化を実行する最初のエージェント型 AI ベースのサービスです。このサービスには 4 つの異なる主要な機能があります。最初のものは VMware 移行に関するもので、既存の VMware 環境を評価し、AWS への移行のコンテキストで適切なネットワーク設計を実行し、アプリケーションのインテリジェントなグループ化による適切なキャパシティプランニングを行い、これらのアプリケーションをクラウドに効果的に移行するのに役立ちます。そして最後になりますが、実際の移行を実行することができます。

2 番目の機能は、フルスタック Windows 現代化に関するもので、追加の高度な機能をリリースしました。AWS Transform はエンドツーエンドの Windows 現代化を実行するためにより強力になりました。.NET 現代化、つまり .NET アプリケーション変換とともに、関連するデータベースの現代化もサポートしています。レガシー .NET Framework から .NET 8 または .NET 10 へのアプリケーション変換を行いたい場合、それに伴い、このアプリケーションの関連するデータベースを SQL Server から Amazon RDS for PostgreSQL、Aurora PostgreSQL、または他のオープンソースデータベースに現代化することができます。これにより、全体的なコストを大幅に改善し、Windows ライセンスの自由度を得ることができます。

3 番目の機能はメインフレーム現代化に関するもので、メインフレームアプリケーション現代化の評価を実行し、ドメイン駆動型アプローチに基づいて適切な分解分析を行う機能があります。また、メインフレームアプリケーション現代化の 3 つのフェーズすべてをサポートできる新しい機能もあります。それは、再構想、リプラットフォーミング、およびアプリケーションのリファクタリングです。また、メインフレームワークロードのテスト作業を大幅に削減するのに役立ちます。そして最後になりますが、カスタム現代化があります。.NET だけでなく、Java から、.NET から Python へ、さらにはエンタープライズコードパターン、デザインパターン、アーキテクチャパターンに基づくカスタムアプリケーションからアプリケーションを変換することができます。これらを採用し、それに応じて変換を実行することができます。

Kiroによるアプリケーション分析とフレームワーク評価

このセッションでは、Windows modernization capability に焦点を当てます。というのも、Unicorn Store アプリケーションは .NET ベースのモノリシックなアプリケーションだからです。では、modernization workflow の最初のフェーズを見てみましょう。ここでは、与えられたアプリケーションのアプリケーション分析を実行し、AI がどのようにそれを支援できるかを確認します。

Anand、ありがとうございます。Anand は本日お話しする 7 段階のアプローチと Unicorn e-commerce アプリケーションについてご説明しました。次のステップは、Quiro を使用して Unicorn アプリケーション自体を見て、その現在のアーキテクチャを理解することです。次のビデオでは、Quiro で Unicorn アプリケーションのコードベースを開きます。その後、自然言語クエリを使用して、Quiro にアプリケーションで使用されているフレームワークは何か、アプリケーションが現在抱えている技術的およびビジネス上の課題は何か、そしてアプリケーションのアーキテクチャを説明するよう質問します。

それが完了したら、Quiro が提供してくれたインサイトを使用して、このアプリケーションの包括的な modernization 戦略を策定します。これには、短期的なクイックウィン、中期的なサービス分解、および長期的なアーキテクチャ変換が含まれます。このデモの後、あなたは自分のアプリケーション内でこの体系的なアプローチを使用し、それらを管理可能でスケーラブルなサービスに分解できるようになるはずです。では、デモに進みましょう。

これが Quiro インターフェースです。左側にエクスプローラーウィンドウが見え、右側にはチャットウィンドウが見えます。Quiro にコードベースを分析させ、使用されている .NET バージョンを特定し、ビジネスおよび技術的な課題が何かを説明するよう質問するつもりです。Quiro は考えており、コードベースを調べています。現在使用されているバージョンが何かを理解しようとしています。.NET 3.0 だと言っています。推奨されるターゲットは何か？.NET 8 です。なぜなら .NET 3.0 は数年前にすでにサポート終了になっているからです。

現在のアーキテクチャはクラシックなモノリシックなアプリケーション間アーキテクチャです。また、cloud-native の制限を含む主要なビジネスおよび技術的な課題も推奨しています。複数のサービス間で共有データベースを使用しているため、共有データ管理の問題を強調しています。モノリシック API により、異なるビジネス機能を拡張することが難しくなっています。即座の推奨事項は何か？.NET 8 にアップグレードし、短期的には bounded context を抽出することです。これについては後で説明します。中期的には完全なマイクロサービスアーキテクチャに移行することです。

AWS Transformを活用した.NET 8へのフレームワーク変換

Quiro がコードベースを分析して、推奨事項を提供してくれました。次のステップとしては、.NET 3.5 フレームワークを使用していることが判明したので、.NET 8 へのアップグレードを推奨しています。このアップグレードに使用するサービスが AWS Transform です。AWS Transform とは何かというと、エンタープライズの .NET、VMware、Windows、メインフレームなどの最新化を加速させるために開発された、エージェント型の AI を搭載したサービスです。これは AWS の 19 年間の移行と最新化に関する経験に基づいており、AI エージェントを使用して、コード分析、アセスメント、リファクタリング、分解、依存関係マッピング、検証、アプリケーションの変換計画など、複雑なタスクを自動化します。

このデモでは、AWS Transform の .NET 機能を使用します。AWS Transform for .NET サービスを使用する方法は 2 つあります。Web エクスペリエンスまたは Web インターフェースを使用する方法、または Visual Studio ツールキット拡張機能を使用する方法です。このデモでは、Visual Studio ツールキット拡張機能を使用します。AWS Transform がどのように機能するかのデモを見てみましょう。

その前に、AWS Transform for .NET が 3 つの重要なステージをどのように進めていくかについても説明したいと思います。最初のステップは分析フェーズです。基本的には、既存の Windows 依存アプリケーションを調べて、Linux 互換性のために変更が必要なコンポーネントを特定します。次に、変換フェーズに進みます。ここで AI エージェントがアプリケーションを .NET 8 アプリケーションに変換します。これが AWS Transform が本当の力を発揮するところです。基本的には、フレームワークのアップグレードと、アプリケーションが Linux 上で実行されるために必要なプラットフォーム固有のコード変更を処理します。これが .NET 8 です。最後に、変換されたアプリケーションがデプロイ前に正しく機能することを確認するための検証を行います。これは移行と最新化が成功することを確認するために重要です。

では、この重要なタスクをどのように実現しているのでしょうか。まず、言語バージョンをアップグレードします。

AWS Transform は、アプリケーション内の古い C コードを見つけて、Linux 互換の C コードに置き換えることで、言語バージョンをアップグレードします。次に、Windows 依存の .NET Framework からより Linux 互換性の高い .NET バージョンにパッケージをアップグレードします。3 番目に、Linux 互換性のためにコードを書き直します。最後に、人間の介入が必要で、Transform が変更を加えることができないオープンエンドなタスクについては、アプリケーションをビルドして Linux 上で正常に実行するために必要な変更について詳細なレポートを提供します。

.NET アプリケーションを最新化することで、Windows への依存から解放され、コストを削減し、Linux 環境の柔軟性を得ることができます。では、デモを見てみましょう。GitHub で Unicorn Store を開いて、Visual Studio Code を開き、AWS Toolkit に進みます。 AWS Transform が接続され、IAM を使用して認証されていることを確認する必要があります。プロジェクトは右側のウィンドウで開かれています。では、プロジェクト自体を右クリックして、AWS Transform オプションでソリューションをポートします。ここにターゲットバージョンが表示されているので、.NET 8 と .NET 10 が利用可能であることがわかります。スタートをクリックすると、AWS Transform Hub が開きます。これは変換計画全体を追跡するために使用されます。

計画が表示されます。Transform が提供する計画をカスタマイズするか、Transform が提供するデフォルト計画を使用するかのいずれかを選択できます。カスタマイズを使用すると、さらにステップを追加できます。変換計画を進めているので、基本的にはアプリケーションをビルドして、すべての依存関係が利用可能であることを確認しようとしています。その後、変換が完了します。上部に変換が完了したことが表示されます。これで詳細な変換レポートをダウンロードできます。

変換レポートでは、更新されたパッケージと変更された API を確認できます。部分的に成功した変換か、完全に成功した変換かどうかを確認できます。部分的に成功した変換の場合は、下に進んでプロジェクトサマリーを確認して、ビルドエラーがないか、どのパッケージが更新されたかを確認できます。 Linux 互換性を確保するために変更されたファイルを確認できます。ファイルの diff を使用して、以前の内容と変更内容を確認し、そのオプションも表示できます。

Linux Readiness セクションに進むことができます。これは Linux 対応性に関する詳細なレポートを提供します。現在使用されているフレームワークスタックが表示されます。次のステップをダウンロードできます。これにより、このアプリケーションが Linux で実行できるようにするために解決する必要がある重大なエラーが通知されます。ステップを確認して、それを実行していることを確認できます。実行する前に必要なすべてのコマンドと変更が提供されます。その後、すべてのファイルの diff を表示して、すべてを選択して変更を適用できます。これにより、すべてのファイルの変更が適用されます。

これでアプリケーションは既に .NET 8 になっています。 .NET 8 バージョンにアップグレードされました。これは Linux 互換性があります。これで .NET 8 にアップグレードされたので、このアプリケーションが正常に実行されることを確認する必要があります。Kiro を使用してそのアプリケーションをビルドします。Kiro に進んで、現在使用されている .NET バージョンが何かを Kiro に尋ねるプロンプトを出します。これで .NET 8 であることが通知されました。これは Kiro が以前に提案したターゲットバージョンです。これで Kiro にアプリケーションをビルドしてローカルで実行するよう依頼します。

Kiro が実際にビルドを行っています。依存関係をチェックして、ローカルコンピュータで実行されている .NET のバージョンを確認します。既に .NET 9 が実行されていることを確認してから、すべての依存関係を復元しようとします。 .NET restore を実行してすべての依存関係を復元します。アプリケーションのビルドが開始され、ビルドが成功したことがわかります。ポート 8080 でリッスンしているという URL が提供されています。その URL をクリックすると、.NET アプリケーション、Unicorn アプリケーションが開きます。これで、ストアから購入したいユニコーンを選択して、送信をクリックできます。ご覧のように、これは Anand が先ほど示したアプリケーションのデモです。

現在は .NET 8 で実行されています。ここで重要なポイントは、このアプリケーションを分解していないということです。まだモノリシックアプリケーションとして実行されていますが、バージョンが .NET 8 にアップグレードされています。では、Anand をステージに呼んで、分解プロセスについて説明してもらいましょう。

Domain-Driven DesignとEvent Stormingによる分解分析の方法論

これまで見てきたことは、アプリケーションを最新バージョンにアップグレードしたということで、次は Unicorn Store アプリケーションをどのように分解できるかについて分析を実行する必要があります。 7 ステップのプロセスから、ステップ 1、2、3 は完了しています。アプリケーション分析を実施し、コードの変換を行い、変換後にアプリケーションが正常に動作していることも検証しました。次は、分解分析を見て、マイクロサービスの適切な候補を特定する必要があります。

これが最も難しい部分です、信じてください。モノリシックアプリケーションをよりモジュール化された、疎結合されたアプリケーションにどのように分割するのか。アプリケーションチームとアプリケーション所有者が既存のモノリシックアプリケーションをより疎結合されたマイクロサービスベースのアーキテクチャに分解しようとする様々な方法があり、異なるピットフォールに陥っています。それらのピットフォールは何ですか？最初のピットフォールは分散モノリシックです。アプリケーション所有者が分散モノリシックに収束するのをよく見かけます。どのように？既存のモノリシックアプリケーションに水平ティアリングを適用しようとするからです。それはどういう意味ですか？それは機能的に関連するモジュール、つまり類似または共通のコンポーネントをグループ化し、モノリシックアプリケーションからサブモジュールまたはサブグループを切り出そうとすることを意味します。モノリシックアプリケーションがあり、関連するコンポーネントをグループ化すると、そのアプリケーションから小さなサブモジュールが出てきます。しかし、それでも複数のことを行っており、モノリシックアプリケーションの特性と設計上の課題を継承しています。

アプリケーションチームが陥るもう 1 つのピットフォールは nanoservices です。それはどういう意味ですか？アプリケーションの垂直ティアリングが原因で発生します。では、アプリケーションの垂直ティアリングとはどういう意味ですか？UI とそれらの UI ページによって駆動されるビジネス機能があるとしましょう。アプリケーション所有者が試みることは、現在持っている異なる UI スクリーンを使用してアプリケーション機能を分割または分解することです。モノリシックアプリケーションが数百の UI ページで構成されている状況を想像してください。最終的に起こる可能性があることは、環境内にそれだけの数の nanoservices を持つことです。これは多くの運用上の課題を課します。なぜなら、数百のサービスを管理する必要があり、環境内のチャッティネスも増加するからです。

これらが一般的な落とし穴であり、そこで重要なのは適切な粒度です。既存のモノリシックなアプリケーションを分解するための鍵となります。では、どうやって適切な粒度にたどり着くのかという質問が出てきます。ここで重要なのは、既存のモノリシックなアプリケーションを実装とテクノロジーの観点からだけでなく、ビジネスドメインの観点からも適切に評価・分析することです。そして、適切なビジネス分析と技術分析を組み合わせることで、適切な粒度にたどり着くことができます。

では、どうやってそれを実現するのでしょうか。適切な粒度にたどり着くのに役立つアーキテクチャ方法論があります。その一つが Domain Driven Design で、Eric Evans による最初の書籍です。彼が述べているのは、テクノロジーは重要ではなく、ソフトウェア開発の主な焦点であるべきではないということです。むしろ、テクノロジーを通じて実行したいビジネス機能と能力が主な焦点であるべきです。それはどういう意味でしょうか。Domain Driven Design は、ビジネスオーナーとアプリケーションオーナーの間で共通の理解を得るのに役立ちます。そうすることで、適切な粒度と適切なアーキテクチャパターンを適用して、正しいソフトウェアを構築することができます。これが Domain Driven Design が提供するものであり、Domain Driven Design がどのように機能するかです。

これが Domain Driven Design が提供するものであり、Domain Driven Design がどのように機能するかです。その主要な概念を見てみましょう。では、ドメインとは何でしょうか。Domain Driven Design は、与えられたアプリケーションをドメインの観点から適切に分析するのに役立ち、ドメインとその異なる境界を理解するのに役立ちます。ドメインは、私たちが働きたい、そしてエンドカスタマーにサービスを提供したいビジネスである可能性があります。Unicorn Store のユースケースでは、小売がドメインです。なぜなら、ウェブ上で実行されている e コマースアプリケーションであり、エンドユーザーに異なる機能を提供しているからです。この小売ドメインは異なるサブドメインを持つことができます。例えば、注文管理モジュールはサブドメインであり、アプリケーションの全体的な注文を管理するのに役立ちます。2 番目は fulfillment です。注文が配置されたら、それらの注文の fulfillment がどのように行われるか、そしてもちろん出荷も行われます。そうすることで、エンドユーザーが購入した製品を彼らに配送することができます。これらは与えられたドメインのサブドメインである可能性があります。では、このサブドメインはさらに 3 つの異なるカテゴリーに分類される必要があります。その一つは core subdomain です。core subdomain とはどういう意味でしょうか。core subdomain は、あなたにとって差別化要因であるサブドメインです。つまり、モダナイズするために気を配るべきもので、ビジネスロジックで構成されています。私たちの場合、それは注文管理、fulfillment 管理、および出荷管理です。2 番目のサブドメインタイプは supporting subdomain です。Supporting subdomains は、core domain がその機能を達成するために必要です。注文管理の例を取ってみましょう。ロイヤルティプログラムを実行しているかもしれません。そのため、ユーザー情報は CRM システムから取得する必要があるかもしれません。つまり、supporting subdomains は、時には構築され、時には外部ソフトウェア製品として購入されるドメインです。最後は generic subdomain です。例えば、ユーザーが製品を購入する場合、まず認証を行い、アプリケーションへの適切なアクセス権を持つ必要があります。generic subdomain は identity システムである可能性があり、これは多くの場合、構築されるのではなく購入されます。なぜなら、それは小売アプリケーションの core domain ではないからです。Unicorn アプリケーションのコンテキストで core subdomain に焦点を当てると、core subdomain は再び異なるコンテキストを持ちます。これは、そのサブドメインの周りで正しいビジネス機能を提供するのに役立ちます。order サブドメインの場合、order サブドメインは異なるコンテキストを持ちます。なぜなら、注文にはアイテムが必要であり、それらのアイテムを購入したエンドユーザーが必要であり、そして行われた支払いが必要だからです。つまり、そのサブドメイン内にはそれに関連する異なるコンテキストがあります。fulfillmentサブドメインの場合も同じことが言えます。つまり、Domain Driven Design は、ドメイン、そのサブドメイン、core subdomain が何であるか、そして core subdomain が異なるコンテキストの観点からどのように構成されているかの適切な分析を評価するのに役立ちます。最終的に、これらのコンテキストは、サブドメインの周りに適切な境界を定義するのに役立ちます。そして、それらの境界は最終的に正しいサービスに収束します。しかし、質問が出てきます。Domain Driven Design は良いです。なぜなら、ビジネスオーナーとアプリケーションオーナーの間で共通の理解を得るのに役立つからです。しかし、これらのサブドメインを理解し始めるにはどうすればよいでしょうか。これらの異なるコンテキストに関する情報を得始めるにはどうすればよいでしょうか。ここで event storming の発明者である Alberto Brandolini が非常に良い引用をしました。ソフトウェアになるのは、専門家の知識ではなく、開発者の理解、あるいは時には誤解です。なぜなら、ビジネスオーナーは 1 つの理解を持つかもしれませんが、アプリケーションオーナーは同じ理解を持たないかもしれないからです。ここで、これら両方の当事者を一緒に持ってくる必要があります。そうすることで、彼らは共有されたコンテキストでドメインを理解することができます。ここで、次のアーキテクチャ方法論である event storming が、ビジネスオーナーとアプリケーションオーナーの間で共有された理解を達成するのに役立つことができます。これはどのように起こるのでしょうか。Event storming はアーキテクチャツールやデザインパターンではありません。これは方法論であり、ビジネスオーナーとアプリケーションオーナーの間で行われるワークショップです。ワークショップの意図は、異なるドメインイベントを特定し、これらのドメインイベントのプロデューサーとコンシューマーを特定することで、ドメインを理解することです。それを特定したら、それらのサブドメインに関連する異なる bounded contexts を特定することができます。そして、それらの bounded contexts は最終的に異なるサービスのブループリントになります。

Event storming には異なる要素があり、ワークショップの意図は、異なるマルチカラーの付箋で表現されるこれら 6 つまたは 7 つの要素を特定することです。最初の付箋または最初の要素は domain event です。与えられたドメインスペースの一部である異なるドメインイベントが何であるかを特定します。例えば、order created、order canceled、または order placed はこれらの異なるタイプのイベントです。イベントは常に過去形で表現されます。つまり、ビジネスコンテキストで何かが起こったということです。

event storming 演習の下で特定する 2 番目の主要な要素はコマンドです。これらのイベントを生成したコマンドは何でしょうか。例えば、誰かが place order または cancel my order のようなコマンドを発行したでしょう。これらのコマンドは最終的にそれらのイベントを生成しています。特定する 3 番目のことは、実際にそれらのコマンドを発行しているアクターが誰であるかです。Unicorn Store のユースケースでは、私はユーザーです。私はアプリケーションにログインして、それらのコマンドを発行しています。マシンである可能性もあります。異なるコマンドを発行するアクターになることができるビジネスプロセスである可能性もあります。

4番目の重要な要素は Aggregate です。 Aggregate は実際にこれらのコマンドを理解して、それらのコマンドを満たすために特定のビジネスロジックを実行するものです。次は Business Policies です。 Event Storming の一部として、異なるビジネスポリシーを特定します。ビジネスポリシーというのは、例えば誰かが注文を置く際に、在庫が検証されているかどうか、支払いが正常に完了しているかどうか、注文を正常に置く前にそれらを確認するといったものです。これらは異なるビジネスフローに対して適用するビジネス検証ルールです。

次は External System です。例えば、注文を置く場合、まず支払いを実行する必要があり、支払いのために外部の支払いゲートウェイを活用するかもしれません。つまり、ビジネスプロセスに関わっている外部コンポーネントは何かということです。そして最後に、View です。これは UI スクリーンの形で表現されており、ユーザーはそこでアプリケーションまたはビジネスの現在の状態を理解して、それに応じてアクションを取ることができます。例えば、自分の注文が置かれたかどうか、自分の注文が発送されたかどうか、またはキャンセルされたかどうかを理解することができます。どのようなものでもあり得ます。

これらすべての要素を特定すれば、Domain Event-Driven Decomposition アプローチに到達します。Domain Events がデコンポジションを駆動するのです。Domain-Driven Design の原則を Event Storming と一緒に適用することで、Microservices ベースのアーキテクチャに基づいてマイクロサービスを特定するのに役立ちます。これはどのように起こるのでしょうか？ Domain Analysis を実行します。Event Storming を適用して、より Bounded Context 固有の情報を使用して Domain Analysis をさらに進め、正しい Bounded Context を特定してから、そこから正しいマイクロサービスに変換します。

Order Management の例を取ると、 Order Processing ユースケースの Event Storming の結果がどのように見えるかというと、私はアクターです。 Place Order というコマンドを実行するユーザーとして、このコマンドは Order is Created というドメインイベントを生成します。このイベントが作成されると、 Validate the Inventory のようなビジネスポリシーが検証されます。在庫に基づいて、注文を正常に置くことができ、それが完了すると、再び別のコマンドを発行することができ、Payment Gateway のような外部システムが存在することができます。それらは Payment is Successful のようなイベントも生成することができます。

この Event Storming 分析を実行して、これらの異なるスティッキーノートと異なるドメインイベントを特定した後、関連するドメインイベントをグループ化して、正しい Bounded Context に収束させようとします。その正しい Bounded Context は、その後、異なるドメインサービスを表します。Order Processing ユースケースのこの例では、Event Storming 分析全体が、Order Management フローをサポートできるコマンドという観点でのアプリケーション機能は何か、Payment のような依存する外部システムは何か、そして Order ライフサイクルの観点で維持する必要がある独自のリポジトリ、つまりデータまたは現在の状態は何かを特定するのに役立ちました。これが、与えられたモノリシックアプリケーションに対して、正しい粒度で正しいデコンポジションを実際に実行する方法です。

KiroとMiroを使用したイベントストーミング分析の実践

では、GenAI がこのイベントストーミング全体と、与えられたアプリケーションのドメイン駆動設計ベースの分析を加速するのにどのように役立つかを見てみましょう。ここでも Kiro を活用しています。私たちは既に Unicorn Store アプリケーションを .NET 8 に変換しています。ここで使用するのは、Kiro にイベントストーミング分析を実行するよう依頼することです。

Kiro にイベントストーミング分析を実行するよう指示するプロンプトを提供します。プロンプトでは、イベントストーミングの 7 つの要素すべてを特定します。ドメインイベントからコマンド、アクター、外部システム、ビジネスポリシー、アグリゲート、主要なロールまでです。Kiro はアプリケーション全体のコードベースを内省し、これらのイベントストーミング要素をすべて特定しようとします。その後、このイベントストーミング分析を使用して定義できる可能性のあるバウンデッドコンテキストをマッピングしようとします。現在、Kiro はその分析を実行中で、分析が完了しました。これで、与えられたアプリケーションに対して Kiro によって特定されたさまざまなドメインイベントを見ることができます。それをハイライトすると、例えば、注文管理イベント、注文作成、注文完了、注文失敗が見えます。または支払いプロセスイベントさえも見えます。ショッピングカートの場合、さまざまなタイプのドメインイベントも同様に特定されています。

ここでの意図は、AI に基づいて完全なイベントストーミングとドメイン駆動設計分析を実行することではなく、この情報は確かにビジネスオーナーとアプリケーションオーナーが独自の評価を実行し、さらに改善できるベースになります。ドメインイベントだけでなく、さまざまなコマンドとさまざまなアグリゲートもすべて、Kiro によって与えられたモノリシックアプリケーション、私たちの場合は Unicorn Store に対して特定されていることが見えます。ドメインイベントを特定しているだけでなく、さらに一歩進んで、可能性のあるバウンデッドコンテキストも提供し、この与えられたレガシーモノリシックアプリケーションから切り出すことができる可能性のあるマイクロサービスをハイライトしています。

これは重要です。なぜなら、この推奨事項は、私たちが以前見た水平または垂直の分割からだけではなく、ドメイン駆動設計やイベントストーミングのような建築方法論から来ており、そこから逆算して、可能性のあるバウンデッドコンテキストと対応するマイクロサービスが何であるかを決定しているからです。この分析を行ったので、次のステップは実際にイベントストーミングを実行することです。ここで Kiro の成果がビジネスオーナーとアプリケーションオーナーのベースになります。彼らは共有ワークショップモードに入り、この分析をさらに最適化し、ビジネス理解と実装理解に応じて修正することができます。このイベントストーミングワークショップは対面で行うこともできますし、仮想で行うこともできます。

私たちは仮想で行う必要があるユースケースを取り上げています。仮想イベントストーミングボードを提供するプラットフォームがあります。そのようなプラットフォームの 1 つが Miro です。Miro は仮想イベントストーミングボードを提供し、さまざまなスティッキーノートをサポートすることで、仮想イベントストーミング演習を実行するのに役立ちます。開発者として、開発者アカウントを作成し、API キーを生成し、これらの API キーを使用して、プログラムでさまざまなイベントストーミングボードを生成できます。私たちは正確にそれを行いたいと考えており、AI 機能を活用して同じことを行っています。Kiro に、実行されたこのイベントストーミング分析に基づいてスクリプトを生成するよう依頼しています。スクリプトは私たちのために Miro ボードを作成し、Unicorn Store アプリケーションのイベントストーミング分析を通じて得られたすべてのこの理解を適用します。Kiro は先に進んでスクリプトを生成します。そのスクリプトで、私たち全員のための仮想イベントストーミングボードを生成します。その後の意図は、その仮想ボードを使用して、プロダクトオーナーとアプリケーションオーナーがさらなるブレーンストーミングを実行し、さまざまなサービス境界とバウンデッドコンテキストを最適化または改善できるようにすることです。ボードが正常に作成されました。

ミラーボードを開くと、すべての異なるドメインイベントがそれぞれのコマンドとどのように関連付けられているかが見えます。これは、ビジネスポリシー、外部システム、その他の要素がどのように異なるコンテキストにグループ化されているかを示しています。ここでは、オーダーマネジメントドメインにズームインした例を見ています。GenAI機能を使用してイベントストーミングとドメイン駆動設計ベースの分析を実施した後、オーダーマネジメントの境界付きコンテキストがどのように構築されたかを見ると、注文処理フロー内のすべての異なるイベントが配置されています。それぞれのコマンド、それぞれの外部システム、そしてそれに関連する他の要素がすべて揃っています。これが、適切な境界と粒度を持つ適切なマイクロサービスを構築するためのブループリントになります。

MCPサーバーによるアーキテクチャ図生成とマイクロサービスへのリファクタリング

次のフェーズでは、生成した境界付きコンテキストに基づいて、モノリシックアプリケーションのアーキテクチャをどのように改善し、イベントストーミングの成果として見た異なる境界付きコンテキストの形で新しいマイクロサービスを構築できるかを見ていきます。そのために、Shriに引き継ぎたいと思います。ありがとうございます。また、MCPについても説明したいと思います。MCPはオープンソースプロトコルで、アプリケーションが大規模言語モデルとどのように通信するかを標準化し、適切なコンテキストを提供します。

スライドの下部を見ると、MCPがあります。左側にはエージェントがあります。これらのエージェントはチャットボット、自律的なワークフロー、またはアプリケーションである可能性があります。右側にはデータソースがあり、これはAPI、内部システム、データベースなどである可能性があります。MCPは真ん中に位置しているので、接着剤として機能します。エージェントが独自のカスタム方法で各システムと統合する代わりに、MCPはツールを説明し、データを共有するための共通で一貫した方法を提供します。つまり、エージェントはより移植性が高くなり、統合は再利用可能になり、新しいエージェントが新しいソースと通信するたびに、または新しい機能が必要になるたびに行わなければならないワンオフの配管工事を避けることができます。

AWSには、多くの再利用可能なMCPサーバーを提供しているGitHubリポジトリがあります。ここで使用するMCPサーバーの1つは、AWS architecture diagram MCP serverです。これはアーキテクチャダイアグラム、フローダイアグラム、シーケンスダイアグラムなどを設計するのに役立つPythonパッケージです。そのMCPサーバーを呼び出します。次のステップは、基本的にKiroに入ってMCPサーバーを設定することです。これは非常に簡単なステップです。GitHubに行ってMCPサーバーを取得し、IDEにMCPサーバーを追加するために従う必要がある指示がそこに記載されています。

それを設定したら、私はすでに行っています。今、Kiroにアーキテクチャダイアグラムを生成するよう依頼しています。デフォルトでは、PNGダイアグラムまたはJPEGダイアグラムが作成されます。しかし、反復して変更できるものが欲しいのです。そのため、Draw.ioというツールをよく使用しています。Kiroに伝えているのは、そのアーキテクチャダイアグラムをDraw.io XML形式で生成してほしいということです。そうすれば、そこから反復を開始しやすくなります。デモを再生してみましょう。Kiroに、AWS diagram MCP serverを使用して、前のセッションから特定された境界付きコンテキストに基づいたAWSマイクロサービスアーキテクチャを示すDraw.io XMLダイアグラムを作成するよう依頼します。MCPサーバーを呼び出すつもりです。MCPツール get_diagram を呼び出しているのが見えます。そして、アーキテクチャダイアグラムを生成してくれます。実際にPNGダイアグラムが生成されました。Draw.io形式を要求しているので、実際にそのファイルをDraw.ioで再作成するつもりです。また、左側に気付いた場合、その特定のファイルが作成されています。データフローパターンがすべて定義されたアーキテクチャダイアグラムが作成されています。Draw.ioを開いたので、作成されたダイアグラムを開くつもりです。

はい、ご覧の通り、これは MCP サーバーによって直接作成されたものです。以前は、管理者やプラットフォームアーキテクト、またはアプリケーションオーナーがこれを作成するのに数日かかっていました。今では MCP サーバーを通じて既に完成しています。これは実際に異なるドメインに基づいて整理されています。ユーザー管理ドメイン、製品カタログドメイン、そして異なるデータがどのように相互に流れるかが示されています。ここでも Lambda が言及されていますが、マイクロサービスなので簡単に置き換えることができます。ECS や EKS、またはコンテナソリューションのいずれかに置き換えることができます。また、通知が関わる外部サービスも特定されています。

具体的には、これには SES のような外部サービスと呼び出す必要があるサードパーティ API、そしてアーキテクチャ図内の監視とロギング機能が含まれています。これは Kiro によって作成された生のダイアグラムです。要件に基づいてこれを反復することができます。

次のステップ、7 番目のステップですが、実際にこのアプリケーション全体を Kiro でマイクロサービスに分解してリファクタリングすることです。Kiro にこのモノリシックコードを異なるマイクロサービスに分割するよう依頼するつもりです。では Kiro にプロンプトを出して、分析と分解をマイクロサービスに行わせます。また、Web API、Entity Framework モデル、データベース、データコンポーネントなど、すべてを個別に生成するよう依頼しています。分析を完了し、マイクロサービスの抽出が完了しました。包括的なプロジェクト構造が作成されたのが見えます。独立したサービスフォルダ、共有アーティファクト、Kubernetes マニフェスト、デプロイメントファイルがあります。左側のフォルダと共有アーティファクトを探索します。左側のフォルダ構造を見ると、catalog、cart、order、user として整理されたサービスが見えます。左側のフォルダ構造を探索すると、cart サービスを含むサービスが見えます。また、API 間のサービスコントラクトを特定でき、サービス間のデータ所有権の問題を特定でき、共通ライブラリとして抽出する必要がある共有コードを特定できます。

以前、最初のスライドで示したように、プロジェクトファイルが 1 つのフォルダの下に整理されていたのを見ました。今では、プロジェクトファイルが異なるフォルダ構造に整理されているのが見えます。各フォルダを確認して、すべてのファイルがそこにあることを確認しているだけです。また、デプロイメントファイルも作成されています。要求しているプラットフォームに応じて、このプロンプトで Kubernetes または EKS デプロイメント用のデプロイメントファイルを作成するよう依頼しました。CloudFormation テンプレートが作成されており、これを使用してそのアプリケーションのインフラストラクチャとアプリケーションコンポーネントをデプロイできます。

では Anand に招待して、モダナイゼーションフローをまとめてもらいます。ありがとうございます、Rie。では最後に、私たちが達成したことは、レガシーなモノリシックアプリケーションから始まり、この Unicorn Store アプリケーションをモダナイズするための 7 ステップのプロセスを実行したということです。まず、Kiro を活用してコード分析を行いました。その後、AWS Transform を使用して既存のアプリケーションを古い .NET フレームワークから .NET 8 に変換しました。その後、与えられたアプリケーションに対してイベントストーミングとドメイン駆動設計分析を行いました。異なるイベントストーミングボードを生成して、適切な粒度で到達できるさまざまな境界付けられたコンテキストを表現し、最終的にそれが適切なマイクロサービスに変換されました。そこから、すべてを Kiro を通じて行い、Kiro の MCP 統合を活用してこれらの新しいマイクロサービスのアーキテクチャ図を生成しました。最後に、レガシーなモノリシックアプリケーションを分解し、再び Kiro を使用してより最新のマイクロサービスベースのアーキテクチャにリファクタリングしました。モダナイゼーションのエンドツーエンドの旅は、AI ベースの機能と異なるアーキテクチャの方法論とプラクティスを活用することで加速されました。

主な要点は何でしょうか？主な要点の一つは、確実に Domain-Driven Design と Event Storming ベースのアプローチを活用して、ドメインの適切な分析を行い、アプリケーション所有者とビジネス所有者の間で正しい共通理解を得て、レガシーアプリケーションを分解するための適切な境界と粒度を定義することです。二つ目は、AWS Transform や Kiro のような AI ベースの機能を活用して、モダナイゼーションを加速させることです。これにより、レガシーアプリケーションスタックのモダナイゼーションに必要な全体的な努力、時間、コストを大幅に削減できます。より速くイノベーションを推進することができます。以上です。本セッションにご参加いただきありがとうございました。ご質問がございましたら、Anand と私が対応可能ですので、ご質問があればお受けします。ありがとうございました。

※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。