ビジネスドメインを見つけてモノリシックアプリケーションのリファクタリングを始めよう

この投稿では、AWS でのドメイン駆動設計の概要を紹介します。レガシーなモノリシックアプリケーション内のビジネスドメインを特定する方法と、それらをマイクロサービスの集合に分解する方法にについて紹介します。マイクロサービスのドメイン駆動設計から始めると、新たにリファクタリングしたアプリケーションでクラウドのスケールメリットを享受できます。最近、AWS は AWS Migration Hub Refactor Spaces の一般提供開始を発表しました。この機能により、ストラングラーフィグパターンを実装して、複数の AWS アカウントでレガシーなアプリケーションとリファクタリングしたアプリケーションの両方を運用できます。

マイクロサービスのメリット

次のような利点を活用し始めるために、レガシーなモノリシックアプリケーションをマイクロサービスの集合に変えようとする企業が増えています。

• ビジネスと技術の俊敏性の向上 – マイクロサービスは、各サービスが1つの役割のみを担当するため、管理と保守がそれほど複雑ではありません。
• スケーラビリティの向上 – マイクロサービスアーキテクチャへの移行により、企業はクラウドネイティブな技術を使用できます。AWS では通常、AWS Lambda、 Amazon Elastic Container Service、または AWS Fargate などのサーバーレスコンピューティングを使用します。これらのサービスを使用すると、需要に合わせて個別にスケーリングできるため、必要なリソースに対してのみ料金を支払うことができます。
• 耐障害性の向上 – マイクロサービスは、単一のモノリシックアプリケーションよりも疎結合です。つまり、何らかの理由で1つのサービスが利用できなくても、残りのアプリケーションサービスには影響がないということです。

ただし、アプリケーションのリファクタリングは困難な場合があり、実装には多大な時間と労力が必要です。主な課題の1つは、各マイクロサービスが新しい環境ですべきことをどのように特定するかです。では、どのようにモノリスを分解し始めるとよいでしょうか？ 新しいマイクロサービスのドメインを特定するには、いくつかの異なるパターンを適用できます。たとえば、顧客向けの銀行向けウェブアプリケーションを考えてみましょう。

分解パターンの例には次のものがあります。

• トランザクションタイプ – この例では、定期支払いのスケジュール設定、1 回限りの支払い、およびユーザーが個人情報を変更するためのマイクロサービスが 1 つ作成されます。これにより、インタラクションのたびにサービス間の追加のネットワーク通信が不要になるため、待ち時間が短くカスタマーエクスペリエンスが向上する可能性があります。ただし、「分散モノリス」の作成にもつながります。 これは、サービスがビジネスのさまざまな部分にわたる複数の機能で構成されているため、サービスが依然として密結合の場合に起こります。これにより、保守や更新が難しくなります。
• 組織的なチーム – この例では、ビジネス内の各開発チームが独自のマイクロサービスを担当しています。これには、チームが他のチームに頼らずに刷新し、サービスを段階的に改善できるという利点があります。各サービスは独立して運用およびスケーリングできますが、サービス間で依存関係が残っていると、大きな変更をリリースするのが難しい場合があります。サービスの変更が両方のチームとって同様のビジネス目標に沿っていない場合、これはさらに悪化します。たとえば、マイクロサービスは営業部門、マーケティング部門、カスタマーサービス部門向けに個別に開発されるとします。各部門がレガシーアプリケーションのさまざまな部分を操作する可能性があるため、このアーキテクチャには、技術的な機能ではなく、明確なビジネスニーズに合わせたソフトウェアを提供できるという利点があります。ただし、このアプローチの欠点は、たいてい新しいマイクロサービスがビジネスモデルと密接に結びついていることです。チームや組織の変更の影響を受けるため、これらのマイクロサービスの更新が困難です。
• ビジネスサブドメイン – これは組織的なチームと似たパターンを使用します。ただし、ビジネス機能はさらにサブドメインに分解されます。これらのサブドメインは通常、それらの用途によってさらに境界が明確になるため、顧客のニーズにより合致したものになります。たとえば、カスタマーサービスには、顧客の詳細を更新するためのマイクロサービス、サポートケースを作成するためのマイクロサービス、ロイヤルティプログラムに登録するためのマイクロサービスがあります。一方、マーケティング部門は、新しいキャンペーンの立ち上げと、分析によるビジネスインサイトの生成に分かれている場合があります。ビジネスサブドメインで分割すると、アーキテクチャとサービスがビジネス目標に合致した緩やかな結合状態になります。各サービスは独立してスケーリングでき、保守と拡張が可能です。これらのサブドメインが何であるかを特定するには、ビジネスリーダーとある程度連携する必要があります。これについては、この記事の残りの部分で詳しく説明します。

ドメイン駆動設計

モノリスをビジネスサブドメイン別に分解するには、ドメイン駆動設計の原則を適用できます。ドメイン駆動設計は、定義されたビジネス目標、つまりエンドカスタマーのニーズに合わせたソフトウェアの提供を容易にするのに役立ちます。イベントストーミングとコンテキストマッピングは、ドメインを特定し、それらが定義したサービスとどのように対応しているかを特定するために使用できる 2 つのアプローチです。サブドメインを定義することで、クラウド向けに最適化された新しいマイクロサービスアーキテクチャの実装を開始できます。

AWS Migration Hub Refactor Spaces では、ストラングラーフィグパターンを使用して、モノリスを新しいマイクロサービスに段階的にリファクタリングできます。これにより、既存のアプリケーションを進化させながら運用し、新しいサービスを作成するたびにトラフィックを段階的にルーティングできます。

ドメイン駆動設計には、ビジネスに関する深い理解が必要です。それには、ビジネスエキスパートと開発者の両方の時間とコミットメントが必要です。ドメイン駆動設計は、「クイック・ウィン」が必要な状況では使用しないでください。 代わりに、支援ドメイン (ビジネスに関連しているが差別化要因ではないドメイン) ではなく、コアビジネスドメイン (ビジネスの主要な差別化要因となるドメイン) をサポートするソフトウェアにドメイン駆動設計を使用してください。ドメイン駆動設計を始めるには、イベントストーミングのセッションが必要です。これは価値のある取り組みです。これにより、エンドユーザーのニーズにより合ったソフトウェアを開発できるようになります。また、よりスケーラブルで保守が容易な分離されたサービスを作成するのにも役立ちます。これらの成果により、ビジネスの俊敏性が向上します。

ドメイン駆動設計は、すべてのソフトウェアに適しているとは限りません。たとえば、CRUD ベースのサービスは一般的にトランザクション型でデータ駆動型です。ただし、複数のサービスに分散していると、不必要に複雑になる可能性があります。この場合、単純なトランザクションにおいてサービス間の調整が必要となるため、ドメイン駆動設計はあまり適していない可能性があります。アプリケーションを十分に分解するのに必要なライセンスを保有しているかどうかを評価することが重要です。つまり、アプリケーション (商用ソフトウェアなど) のコードを完全に所有していない場合、ドメイン駆動設計を使用してサブドメインに分割できない可能性があります。

イベントストーミングと境界づけられたコンテキスト

イベントストーミングは、ビジネスチームとテクノロジーチームの両方がソリューションが提供すべき内容について意見を一致させるのに役立つワークショップとして普及しています。これは、実装方法の詳細に気を取られることなく行われます。つまり、チームがソースコードのデリバリーを開始するまでに時間がかかる可能性があります。しかし、すべてのチームは、各マイクロサービスが何を担当するべきかについて、より良い調整を行うことができます。イベントストーミングの結果、利害関係者は「ユビキタス言語」を話すことになり、ソリューションで何をすべきかについて混乱することはほとんどありません。

イベントストーミングのワークショップはブレインストーミングの練習です。このセッションでは、ソリューションのすべての利害関係者が協力して、ドメインに対応するビジネスイベントを特定します。銀行業務の例では、新しい口座を申請する顧客がビジネスイベントになることがあります。ワークショップでは、グループはイベントのトリガーとなるエンティティ、結果的に発生する必要なプロセス、およびソースイベントからトリガーされる後続イベントの特定を始めます。

イベントストーミングセッションの後、チームはビジネスのドメインを特定し、次に業務を行うコンテキストを特定できます。これらを使用して、各マイクロサービスとそのコンテキストとの間で行われる用途や通信を特定できます。ビジネスエキスパートの助けを借りてドメインを定義したら、開発者はソリューションの設計を開始できます。

イベントストーミングセッションから得られる成果物はドメインモデルです。ドメインモデルを使用して、一連の境界づけられたコンテキストを識別できます。境づけられたコンテキストは、各ドメインが適用される境界です。口座開設の例は、銀行の「口座オンボーディングコンテキスト」と考えることができます。 システム全体には、支払いコンテキスト、取引コンテキスト、詐欺コンテキストなど、他のコンテキストもあります。異なる境界づけられたコンテキスト間の通信を引き起こすビジネスイベントを特定することで、マイクロサービスが新しいアーキテクチャでどのように相互に通信するのか把握できます。

このコンテキストマップの例は、銀行アプリケーションに含まれる可能性のあるコアドメインのサンプルのみを示しています。また、支援ドメインやそれに続くドメインも多数存在します。たとえば、口座開設が完了した後に新しいデビットカードを顧客に発送します。これを管理するサービスが必要ですが、口座開設アプリケーションのコアドメインには含まれていません。

マイクロサービスへの段階的リファクタリング

モノリスを分解したら、次の疑問は、どのリクエストをモノリスにルーティングするか、新しいマイクロサービスに送信するかを管理する方法です。この課題は、 AWS Migration Hub Refactor Spacesを立ち上げることでより簡単になります。AWS Refactor Spaces 環境では、アプリケーションプロキシをレガシーサービスとリファクタリングされたサービスの両方に設定できます。最初は、モノリスアプリケーションのエンドポイントがデフォルトサービスになります。これは、新しいマイクロサービスが開発されるまで、トラフィックが引き続きレガシーアプリケーションにルーティングされるようにするためです。マイクロサービスを使用する準備ができたら、サービスを追加し、そのサービスを Refactor Spaces アプリケーションにルーティングできます。これは、発生したインフラストラクチャやアプリケーションの変更からエンドユーザーを保護しながら行われます。さらに、AWS Refactor Spaces がお客様に代わってネットワークファブリックを管理します。API Gateway と Transit Gateway の環境をオーケストレーションして、トラフィックを新しいサービスにルーティングできるようにします。その後、ストラングラーフィグパターンを使用して、新しいサービスを Refactor Spaces アプリケーションに段階的に追加できます。これは、最終的にすべてのトラフィックがモノリスから新しいマイクロサービスによって処理されるようにするためです。

次の図は、銀行アプリケーションの例で新しいマイクロサービスを段階的に追加しているときに、モノリスがどのようにトラフィックの一部を受け取るかを示しています。アプリケーションユーザーは、モノリスからマイクロサービスへの変更から保護されます。

まとめ

このブログでは、イベントストーミングワークショップを通じてドメイン駆動設計を使用してモノリシックアプリケーションをマイクロサービスの集合に分解する方法と、AWS Migration Hub Refactor Spaces がクラウドネイティブな技術を活用してマイクロサービスを実行し始める際の面倒な作業をどのように軽減できるかを説明しました。

AWS Migration Hub Refactor Spaces の詳細については、 Migration Hub コンソールをご覧ください。

著者について