はじめに
前回のpart4に引き続きアーキテクチャの解説をしていきます。今回はタイトルでもあるように、「DIP」、「ヘキサゴナルアーキテクチャ」について紹介します。なお、「ヘキサゴナルアーキテクチャ」については少しボリュームがあるので、次回より深く解説しようと思います。
では、さっそく始めていきます！
DIP（依存関係逆転の原則）を用いたレイヤ化アーキテクチャとは
DIPとは、「Dependency Inversion Principle」の略で、これをそのまま日本語に訳したものが「依存関係逆転の原則」となります。
概要を紹介すると、「今までのように上位が下位に依存することをやめて、関係を逆転させよう」というものです。「抽象は、実装の詳細に依存すべきではない。実装の詳細が、抽象に依存すべき」ともいえます。
下の画像が概念図を表しています。
名前の通り上下関係が逆転していることがわかります。
このアーキテクチャでは、ドメインが他のレイヤに依存しなくなるので、ドメイン層を独立させ、シンプルに管理しやすくなります。
さて、一応紹介してみたもの、依然としてイメージが難しいと思うのでここからはもっとかみ砕いて説明しようと思います。
まず前提知識として、表示を担当する「プレゼンテーション層」を設けた場合、それは「UI層」などの変更によりコードを書き換えなければならないことがありがちだということを頭に入れておいてください。
つまり、「プレゼンテーション層」は安定性が低く、柔軟性が求められるということです。一方で、「ドメイン層」はルールや制約（システムの本質）を定義するため、柔軟性が求められることはほぼありません。例として、じゃんけんのゲームを開発する際、「パーはグーに負ける」というような絶対的なルールは変更できないでしょう。
ここで、先ほど紹介した概要を振り返ってみましょう。DIPにおいて、上位（抽象）を「UI層」、下位（実装）を「ドメイン層」とすると、「ドメイン層」は「UI層」に依存する形なります。
依存関係が成立する場合、依存する側は安定性が低く、柔軟性が高くなりがちである。これは、仮にモジュールのimportを考えると、依存する側のコードはより複雑になる（理解が難しくなる）からです。
このことを踏まえると、DIPの具体例として、「ドメイン層」で「UI層」のモジュールをimportするのはやめよう、ということが挙げられます。
ヘキサゴナルアーキテクチャについて
「はじめに」で述べた通り、今回はヘキサゴナルアーキテクチャの概要だけ紹介します。
先ほど紹介したDIPを採用することでドメインの独立性は高まりました。しかし同時に、「インフラストラクチャ層」（DIP採用時に一番上位に位置づけられるもの）の実装は複雑になってしまします。そこで、その問題を解決するために考え出されたのがこの「ヘキサゴナルアーキテクチャ」です。まず簡単にイメージを表した以下の画像に軽く目を通してください。
ヘキサゴナルアーキテクチャにおいて押さえておきたいポイントは以下の3つです。
- ビジネスロジックが中心である
- ユーザー操作などの入力側、データベースなどの出力側のどちらも差し替え可能である
- 部品を自由に入れ替えられる
ここでいう「非対称的」とは、データや操作の流れが一方的（一方的に依存する関係）であるということである。
しかし、ヘキサゴナルアーキテクチャでは、上の画像であるように、「ドメイン」を中心において「処理をするプライマリ（Primary）側」、「処理が駆動されるセカンダリ（Secondary）側」と連携します。具体的に説明すると、プライマリ側は主となる入力（ドメイン層）を呼び出す役割を、セカンダリ側は
ドメインが外部に処理結果を出力したり、データの保存などをしたりします。
ポート＆アダプター
ヘキサゴナルアーキテクチャはそのつくりの仕組みから、「ポート＆アダプター」とも呼ばれます。「ポート」はシステムの目的に応じて設計され、前述したような差し替え可能部分は「アダプター」として用意されます。上の画像と同じことを説明することになりますが、「ドメイン」部分はユースケースをもとに設計し、「ポート＆アダプタ部分」は技術的なインターフェイス（通信や記録など）をそれぞれで設計するイメージとなります。
メリット
さて、ヘキサゴナルアーキテクチャについて長々と説明しました。「結局何がうれしいのか」を説明して今回の記事は終わりにします。
ヘキサゴナルアーキテクチャはその仕組みから、柔軟なアーキテクチャであることは理解できたと思います。柔軟なアーキテクチャの良いところは他のアーキテクチャもうまく取り込めることです。加えて、周辺の技術が決まっていなくても、暫定的に「アダプター」を作成し、ドメインの開発を進めることができます。
さらにうまく設計すると、ドメイン層のロジックを完結させることでユースケースを適切に実装できます。
おわりに
今回はDDDとヘキサゴナルアーキテクチャの概要を紹介しました。はじめに書いた通り、ヘキサゴナルアーキテクチャではもう少し追加で触れておきたい部分があるのでそこを次回は紹介します。
では、最後までお読みいただきありがとうございました。次回もよろしくお願いします。
参考
「実践ドメイン駆動設計」から学ぶDDDの実装入門/青木 淳夫
実践DDD本 第4章「アーキテクチャ」 ～レイヤからヘキサゴナルへ～
【SOLID原則】依存性逆転の原則 - DIP
ドメインモデル中心のアーキテクチャ