# REL03-BP02 特定のビジネスドメインと機能に重点を置いたサービスを構築する
<a name="rel_service_architecture_business_domains"></a>

サービス指向アーキテクチャ (SOA) は、ビジネスニーズに合わせて明確に定義された機能を備えたサービスを定義します。マイクロサービスは、ドメインモデルと制限付きコンテキストを使用して、ビジネスコンテキストの境界に沿ってサービスの境界を描きます。ビジネスドメインと機能に重点を置くことで、チームがサービスの独立した信頼性要件を定義しやすくなります。コンテキストに制限があると、ビジネスロジックが分離されてカプセル化されるため、チームは障害の処理方法について、より的確に判断できるようになります。

 **期待される成果:** エンジニアとビジネス関係者は共同で境界のあるコンテキストを定義し、それを使用して、特定のビジネス機能を果たすサービスとしてシステムを設計します。これらのチームは、イベントストーミングなどの確立された手法を使用して要件を定義します。新しいアプリケーションは、境界を明確に定義し、疎結合するサービスとして設計されます。既存のモノリスは[境界コンテキスト](https://martinfowler.com/bliki/BoundedContext.html)に分解され、システム設計は SOA またはマイクロサービスアーキテクチャに移行します。モノリスをリファクタリングする際には、バブルコンテキストやモノリスの分解パターンなどの確立されたアプローチが適用されます。

 ドメイン指向のサービスは、状態を共有しない 1 つ以上のプロセスとして実行されます。サービスは需要の変動に個別に対応し、ドメイン固有の要件に照らして障害シナリオを処理します。

 **一般的なアンチパターン:** 
+  チームは、特定のビジネスドメインではなく、UI や UX、ミドルウェア、データベースなどの特定の技術ドメインを中心に形成される。
+  アプリケーションがドメインの担当範囲にまたがっている。限定されたコンテキストにまたがるサービスは、メンテナンスが難しく、大規模なテスト作業が必要になり、複数のドメインチームがソフトウェア更新に参加する必要がある。
+  ドメインエンティティライブラリと同様に、ドメイン依存関係がサービス間で共有されるため、あるサービスドメインを変更すると、他のサービスドメインも変更する必要がある。
+  サービス契約とビジネスロジックはエンティティを共通かつ一貫したドメイン言語で表現していないため、翻訳層が発生し、システムが複雑になり、デバッグ作業が増加する。

 **このベストプラクティスを活用するメリット:** アプリケーションは、ビジネスドメインによって区切られた個別のサービスとして設計され、共通のビジネス言語を使用します。サービスは個別にテストおよびデプロイできます。サービスは、実装されたドメインのドメイン固有の回復力要件を満たします。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 ドメイン駆動型設計 (DDD) は、ビジネスドメインを中心にソフトウェアを設計および構築するための基本的なアプローチです。ビジネスドメインに焦点を当てたサービスを構築する際には、既存のフレームワークを使用すると便利です。既存のモノリシックアプリケーションを扱う場合は、確立された手法を提供する分解パターンを利用してアプリケーションをモダナイズし、サービスにすることができます。

![\[ドメイン駆動型設計のアプローチを示すフローチャート。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/domain-driven-decision.png)


 

## 実装手順
<a name="implementation-steps"></a>
+  チームは[イベントストーミング](https://serverlessland.com/event-driven-architecture/visuals/event-storming)ワークショップを開催して、軽量の付箋形式でイベント、コマンド、集計、ドメインをすばやく特定できます。
+  ドメインエンティティと関数がドメインコンテキストで形成されたら、[境界コンテキスト](https://martinfowler.com/bliki/BoundedContext.html)を使用してドメインをサービスに分割できます。境界コンテキストでは、類似の特徴と属性を共有するエンティティがグループ化されます。モデルをコンテキストに分割すると、マイクロサービスを境界で区切る方法のテンプレートが現れます。
  +  例えば、Amazon.com ウェブサイトエンティティには、パッケージ、配送、スケジュール、料金、割引、通貨などがあります。
  +  パッケージ、配送、スケジュールは出荷コンテキストにグループ化され、料金、割引、通貨は料金設定コンテキストにグループ化されます。
+  [モノリスをマイクロサービスに分解すると](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)、マイクロサービスをリファクタリングするためのパターンが概説されます。ビジネス機能、サブドメイン、またはトランザクション別に分解するパターンを使用することは、ドメイン駆動のアプローチに適しています。
+  [バブルコンテキスト](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)などの戦術的な手法を使用すると、事前に書き直したり、DDD に全面的にコミットしたりすることなく、既存のアプリケーションまたはレガシーアプリケーションに DDD を導入できます。バブルコンテキストアプローチでは、サービスマッピングと調整、または新しく定義されたドメインモデルを外部の影響から保護する[破損防止層](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)を使用して、小さな境界コンテキストが確立されます。

 チームがドメイン分析を行い、エンティティとサービス契約を定義したら、AWS のサービスを活用し、ドメイン駆動型の設計をクラウドベースのサービスとして実装できます。
+  ドメインのビジネスルールを実践するテストを定義することから開発を始めましょう。テスト駆動型開発 (TDD) と動作駆動型開発 (BDD) は、チームがサービスをビジネス上の問題の解決に集中させるのに役立ちます。
+  ビジネスドメインの要件と[マイクロサービスアーキテクチャ](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)に最適な [AWS のサービス](https://aws.amazon.com/microservices/)を選択します。
  +  [AWS サーバーレス](https://aws.amazon.com/serverless/)を使用すると、チームはサーバーやインフラストラクチャの管理ではなく、特定のドメインロジックに集中できます。
  +  [AWS のコンテナ](https://aws.amazon.com/containers/)を使用すると、インフラストラクチャの管理が簡素化されるため、ドメイン要件に集中できます。
  +  [目的別データベース](https://aws.amazon.com/products/databases/)は、ドメイン要件を最適なデータベースタイプに一致させるのに役立ちます。
+  [AWS にヘキサゴナルアーキテクチャを構築することで](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)、ビジネスドメインから逆算してサービスにビジネスロジックを構築し、機能要件を満たして統合アダプターをアタッチするためのフレームワークの概要が示されます。インターフェイスの詳細と AWS のサービスのビジネスロジックを分離するパターンは、チームがドメインの機能に集中し、ソフトウェアの品質を向上させるのに役立ちます。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [REL03-BP01 ワークロードをセグメント化する方法を選択する](rel_service_architecture_monolith_soa_microservice.md) 
+  [REL03-BP03 API ごとにサービス契約を提供する](rel_service_architecture_api_contracts.md) 

 **関連ドキュメント:** 
+ [AWS マイクロサービス](https://aws.amazon.com/microservices/)
+  [AWS でのマイクロサービスの実装](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [モノリスをマイクロサービスに分割する方法](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [レガシーシステムに囲まれているときの DDD の使用開始](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+ [エリック・エヴァンスのドメイン駆動設計: ソフトウェアの核心にある複雑さに立ち向かう](https://www.amazon.com/gp/product/0321125215)
+ [AWS でヘキサゴナルアーキテクチャを構築する](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [マイクロサービスへのモノリスの分解](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [イベントストーミング](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [制限されたコンテキスト間のメッセージ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [マイクロサービス](https://www.martinfowler.com/articles/microservices.html)
+ [テスト駆動型開発](https://en.wikipedia.org/wiki/Test-driven_development)
+ [動作駆動型開発](https://en.wikipedia.org/wiki/Behavior-driven_development)

 **関連する例:** 
+ [AWSでのクラウドネイティブマイクロサービスの設計 (DDD/EventStormingWorkshop より)](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)

 **関連ツール**: 
+ [AWS クラウドデータベース](https://aws.amazon.com/products/databases/)
+ [AWS でのサーバーレス](https://aws.amazon.com/serverless/)
+ [AWS でのコンテナ](https://aws.amazon.com/containers/)