

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 概要
<a name="overview"></a>

## ドメイン駆動型設計 (DDD)
<a name="ddd"></a>

[ドメイン駆動型設計 (DDD)](https://www.oreilly.com/library/view/implementing-domain-driven-design/9780133039900/) では、ドメインはソフトウェアシステムの中核です。ドメインモデルは、他のモジュールを開発する前に最初に定義され、他の低レベルモジュールに依存しません。代わりに、データベース、プレゼンテーションレイヤー、外部 APIsなどのモジュールはすべてドメインに依存します。

DDD では、アーキテクトは技術的な分解ではなくビジネスロジックベースの分解を使用して、ソリューションを境界のあるコンテキストに分解します。このアプローチの利点については、[ターゲットを絞ったビジネス成果](#business-outcomes)「」セクションで説明します。

チームが六角形アーキテクチャを使用する場合、DDD は実装が容易になります。六角形アーキテクチャでは、アプリケーションコアはアプリケーションの中心です。ポートとアダプターを介して他のモジュールから切り離され、他のモジュールに依存しません。これは DDD と完全に一致します。ここで、ドメインはビジネス上の問題を解決するアプリケーションの中核です。このガイドでは、六角形アーキテクチャのコアを境界コンテキストのドメインモデルとしてモデル化するアプローチを提案します。次のセクションでは、六角形アーキテクチャについて詳しく説明します。

このガイドでは、非常に広範なトピックである DDD のすべての側面を網羅しているわけではありません。理解を深めるには、[ドメイン言語](https://www.domainlanguage.com/ddd/)のウェブサイトに記載されている DDD リソースを確認してください。

## 六角形アーキテクチャ
<a name="hexagonal"></a>

ポート*やアダプター*、*オニオン*アーキテクチャとも呼ばれる六角形アーキテクチャは、ソフトウェアプロジェクトの依存関係の逆転を管理する原則です。六角形アーキテクチャは、ソフトウェアの開発時にコアドメインのビジネスロジックに重点を置き、外部統合ポイントをセカンダリとして扱います。六角形アーキテクチャは、ソフトウェアエンジニアがテスト駆動型開発 (TDD) などのベストプラクティスを採用するのに役立ちます。これにより、[アーキテクチャの進化](https://dzone.com/articles/pattern-of-the-month-red-green-refactor)が促進され、複雑なドメインを長期的に管理できるようになります。

六角形アーキテクチャと、構造化ソフトウェアプロジェクトのモデリングに最も人気のあるクラシックレイヤードアーキテクチャを比較してみましょう。2 つのアプローチには微妙ですが強力な違いがあります。

レイヤードアーキテクチャでは、ソフトウェアプロジェクトは階層で構成されており、ビジネスロジックやプレゼンテーションロジックなどの幅広い懸念事項を表します。このアーキテクチャでは、依存関係階層を使用します。上位レイヤーは下位レイヤーに依存しますが、その逆ではありません。次の図では、プレゼンテーションレイヤーがユーザーとのやり取りを担当するため、ユーザーインターフェイス、APIs、コマンドラインインターフェイス、および同様のコンポーネントが含まれます。プレゼンテーションレイヤーは、ドメインロジックを実装するビジネスレイヤーに依存しています。ビジネスレイヤーには、データアクセスレイヤーと複数の外部サービスへの依存関係があります。

![クラシックレイヤードアーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hexagonal-architectures/images/layered.png)


この設定の主な欠点は、依存関係構造です。たとえば、データベースにデータを保存するモデルが変更されると、データアクセスインターフェイスに影響します。データモデルを変更すると、データアクセスインターフェイスに依存するビジネスレイヤーにも影響します。その結果、ソフトウェアエンジニアはドメインロジックに影響を与えずにインフラストラクチャを変更することはできません。これにより、リグレッションバグの可能性が高まります。

六角形アーキテクチャは、次の図に示すように、依存関係を別の方法で定義します。これにより、すべてのインターフェイスを定義するドメインビジネスロジックを中心に意思決定が集中されます。外部コンポーネントは、*ポート*と呼ばれるインターフェイスを介してビジネスロジックとやり取りします。ポートは、ドメインと外部ワールドの相互作用を定義する抽象化です。各インフラストラクチャコンポーネントはこれらのポートを実装する必要があるため、これらのコンポーネントの変更がコアドメインロジックに影響を与えなくなります。

![六角形アーキテクチャ](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/hexagonal-architectures/images/hexagonal.png)


周囲のコンポーネントは*アダプター*と呼ばれます。アダプターは、外部ワールドと内部ワールド間のプロキシであり、ドメインで定義されたポートを実装します。アダプターは、プライマリとセカンダリの 2 つのグループに分類できます。プライマリアダプターは、ソフトウェアコンポーネントへのエントリポイントです。これにより、外部のアクター、ユーザー、サービスがコアロジックとやり取りできるようになります。 AWS Lambda はプライマリアダプターの良い例です。Lambda 関数をエントリポイントとして呼び出すことができる複数の AWS サービスと統合されます。セカンダリアダプターは、外部ワールドとの通信を処理する外部サービスライブラリラッパーです。セカンダリアダプターの良い例は、データアクセス用の Amazon DynamoDB クライアントです。

## ターゲットを絞ったビジネス成果
<a name="business-outcomes"></a>

このガイドで説明する六角形アーキテクチャは、以下の目的を達成するのに役立ちます。
+ [開発サイクルを改善して市場投入までの時間を短縮する](improve-dev-cycle.md)
+ [ソフトウェア品質の向上](improve-software-quality.md)
+ [より簡単に変更できる](adapt-to-change.md)

これらのプロセスについては、以下のセクションで詳しく説明します。