REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する
サービス指向アーキテクチャ (SOA) は、ビジネスニーズに合わせて明確に定義された機能を備えたサービスを定義します。マイクロサービスは、ドメインモデルと制限付きコンテキストを使用して、ビジネスコンテキストの境界に沿ってサービスの境界を描きます。ビジネスドメインと機能に重点を置くことで、チームがサービスの独立した信頼性要件を定義しやすくなります。コンテキストに制限があると、ビジネスロジックが分離されてカプセル化されるため、チームは障害の処理方法についてより的確に判断できるようになります。
期待される成果: エンジニアとビジネス関係者は共同で境界のあるコンテキストを定義し、それを使用して特定のビジネス機能を果たすサービスとしてシステムを設計します。これらのチームは、イベントストーミングなどの確立された手法を使用して要件を定義します。新しいアプリケーションは、境界を明確に定義し、ゆるく結合するサービスとして設計されています。既存のモノリスは 境界コンテキストに分解され、
ドメイン指向のサービスは、状態を共有しない 1 つ以上のプロセスとして実行されます。需要の変動に独自に対応し、ドメイン固有の要件に照らして障害シナリオを処理します。
一般的なアンチパターン:
-
チームは、特定のビジネスドメインではなく、UI や UX、ミドルウェア、データベースなどの特定の技術ドメインを中心に形成されます。
-
アプリケーションはドメインの担当範囲にまたがります。限定されたコンテキストにまたがるサービスは、メンテナンスが難しく、大規模なテスト作業が必要になり、複数のドメインチームがソフトウェアアップデートに参加する必要がある場合があります。
-
ドメインエンティティライブラリと同様に、ドメイン依存関係はサービス間で共有されるため、あるサービスドメインを変更すると、他のサービスドメインも変更する必要があります。
-
サービス契約とビジネスロジックは、エンティティを共通で一貫性のあるドメイン言語で表現しないため、翻訳層が複雑になり、デバッグ作業が増えます。
このベストプラクティスを活用するメリット: アプリケーションは、ビジネスドメインによって区切られた独立したサービスとして設計され、共通のビジネス言語を使用します。サービスは独立してテストおよびデプロイできます。サービスは、実装されたドメインのドメイン固有の耐障害性要件を満たします。
このベストプラクティスを活用しない場合のリスクレベル: 高
実装のガイダンス
ドメイン主導型意思決定 (DDD) は、ビジネスドメインを中心にソフトウェアを設計および構築するための基本的なアプローチです。ビジネスドメインに焦点を当てたサービスを構築する際には、既存のフレームワークを使用すると便利です。既存のモノリシックアプリケーションを扱う場合は、確立された手法を提供する分解パターンを利用して、アプリケーションをモダナイズしてサービスにすることができます。
ドメイン主導の意思決定
実装手順
-
チームは イベントストーミング
ワークショップを開催して、軽量の付箋形式でイベント、コマンド、集計、ドメインをすばやく特定できます。 -
ドメインのエンティティと機能をドメインコンテキストで形成したら、以下のようにドメインをサービスに分割できます。 境界コンテキスト
、そこで類似した機能と属性を共有するエンティティがグループ化されます。モデルをコンテキストに分割したら、マイクロサービスを境界で区切る方法のテンプレートが現れます。 -
例えば、Amazon.com ウェブサイトエンティティには、パッケージ、配送、スケジュール、料金、割引、通貨などがあります。
-
パッケージ、配送、スケジュールは出荷コンテキストにグループ化され、料金、割引、通貨は料金設定コンテキストにグループ化されます。
-
-
モノリスのマイクロサービスへの分解 マイクロサービスをリファクタリングするためのパターンを概説します。ビジネス機能、サブドメイン、またはトランザクション別に分解するパターンを使用することは、ドメイン主導のアプローチによく合います。
-
バブルコンテキストなどの 戦術的なテクニックを使用すると、
事前に書き直したり、DDD に全面的にコミットしたりすることなく、既存またはレガシーアプリケーションに DDD を導入できます。バブルコンテキストアプローチでは、サービスマッピングと調整、または 破損対策レイヤー を使用して小さな境界コンテキストが確立され、新しく定義されたドメインモデルを外部の影響から保護します。
チームがドメイン分析を行い、エンティティとサービス契約を定義したら、AWS のサービスを活用してドメイン主導型の設計をクラウドベースのサービスとして実装できます。
-
ドメインのビジネスルールを実践するテストを定義することから開発を始めましょう。テスト駆動開発 (TDD) と行動主導開発 (BDD) は、チームがサービスをビジネス上の問題の解決に集中させるのに役立ちます。
-
ビジネスドメインの要件とマイクロサービスアーキテクチャに最適な AWS のサービスは
を 選択する: -
AWS サーバーレス
を使用すると、チームはサーバーやインフラストラクチャを管理するのではなく、特定のドメインロジックに集中できます。 -
AWS でのコンテナ
インフラストラクチャの管理が簡素化されるため、ドメイン要件に集中できます。 -
目的別データベース
は、ドメイン要件を最適なデータベースタイプに一致させるのに役立ちます。
-
-
AWS 上でヘキサゴナルアーキテクチャを構築すると、 ビジネスドメインから逆算してサービスにビジネスロジックを構築して機能要件を満たし、統合アダプターを接続するフレームワークの概要が示されます。インターフェイスの詳細と AWS のサービスのビジネスロジックを分離するパターンは、チームがドメインの機能に集中し、ソフトウェアの品質を向上させるのに役立ちます。
リソース
関連するベストプラクティス:
関連するドキュメント:
関連サンプル:
関連ツール:
