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