ヘキサゴナルアーキテクチャとは？初心者でも分かる基礎と実践ガイド共起語・同意語・対義語も併せて解説！

この記事を書いた人

高岡智則

年齢：33歳性別：男性職業：Webディレクター（兼ライティング・SNS運用担当）居住地：東京都杉並区・永福町の1LDKマンション出身地：神奈川県川崎市身長：176cm 体系：細身〜普通（最近ちょっとお腹が気になる）血液型：A型誕生日：1992年11月20日最終学歴：明治大学・情報コミュニケーション学部卒通勤：京王井の頭線で渋谷まで（通勤20分）家族構成：一人暮らし、実家には両親と2歳下の妹恋愛事情：独身。彼女は2年いない（本人は「忙しいだけ」と言い張る）

ヘキサゴナルアーキテクチャとは？

ヘキサゴナルアーキテクチャは、ソフトウェアの設計を「中心となるビジネスロジック」と「外部の技術的な細部」に分けて考える考え方です。英語では Hexagonal Architecture と呼ばれ、作者は Alistair Cockburn です。日本語では「六角形アーキテクチャ」とも訳されますが、名称よりも考え方の理解が重要です。

このアーキテクチャの大きなポイントは、中心の ビジネスロジックを外部の依存から分離することです。外部とはデータベース、ウェブAPI、ユーザーインターフェース、ファイルシステム、メッセージングなどを指します。外部の技術的な変更が発生しても、中心の処理は影響を最小限に抑えられます。

基本のアイデア

六角形の真ん中には ビジネスロジック、その周りを取り囲む複数のポートとアダプターが配置されます。中心には業務のルールや計算、判断のロジックがあり、外部と接触する部分だけがポートの役割を果たします。ポートは「どのような入力を受け取り、どのような出力を返すべきか」を定義する契約です。

ポートとアダプターの仕組み

・ ポート は中心のビジネスロジックと外部をつなぐ契約です。何を受け取り、何を返すかを決める設計図です。

・ アダプター はポートの契約を具体的な技術に結びつける実装です。データベース接続を表すアダプター、ウェブAPIを呼び出すアダプター、ユーザーインターフェースからのイベントを受け取るアダプターなどがあります。

<th>役割

説明
中心（ビジネスロジック）	業務のルールや計算など、アプリの本質的な処理を実装します。
ポート	中心と外部を結ぶ契約。何を受け取り、何を返すかを決める設計図です。
アダプター	ポートの契約を具体的な技術に結びつける実装。データベースやAPIなどを接続します。

なぜこの設計が役立つのか

この設計の大きな利点は 変更に強い柔軟性 です。たとえばデータベースを別の種類に変えるとき、中心のビジネスロジックはそのままに新しいアダプターを用意すれば済みます。テストも楽になります。中心のロジックをモックで検証できるため、外部のシステムが必ずしも動作していなくてもロジックの正しさを確認できます。

実践のコツとよくある誤解

・外部依存を一箇所にまとめるような構成を心がけると、変更点が少なくなり保守性が上がります。

・初めは「ポート」と「アダプター」の境界を小さく作ると取り組みやすいです。最初の小さな例として、簡単なデータの入出力をポートとアダプターで実装してみると理解が深まります。

初心者向けの例

たとえば、あるアプリが「ユーザーの購買履歴」を扱うとします。中心は「購買履歴を分析する処理」です。外部には「データベース」「ウェブAPI」「ファイル保存」などがあり、それらはアダプターを介してポートに接続します。こうすることで「分析ロジック」を他のデータソースに対しても再利用しやすくなります。

まとめ

ヘキサゴナルアーキテクチャは、中心のビジネスロジックを外部の影響から守り、テストと保守をしやすくする設計思想です。ポートとアダプターという仕組みを使って、外部技術の変更をロジックに波及させずに済ませることができます。

ヘキサゴナルアーキテクチャの同意語

ヘキサゴナルアーキテクチャ: ビジネスロジックを中心に据え、外部の入出力をポート（インターフェース）とアダプターの組み合わせで接続する、境界駆動型のアーキテクチャ。外部依存をポートとアダプターで分離し、実装を柔軟に差し替えやすくします。
六角形アーキテクチャ: ヘキサゴナルアーキテクチャの別名で、同じ設計思想を指します。中央のドメインと周囲のポート／アダプターの関係を六角形で表すイメージです。
ポートとアダプタアーキテクチャ: 英語表現 Ports and Adapters Architecture の日本語直訳。外部システムとの接続点（ポート）とそれを実装する適合部品（アダプター）で内部と外部を分離します。
ポートアダプタアーキテクチャ: 同じ概念を指す別表現。読み方や表記の違いによる名称の揺れです。
ポート駆動アーキテクチャ: ポートを起点に設計を進める考え方を表す言い回し。正式名称ではない場合もありますが、概念を伝えるのに使われることがあります。
ポート駆動型アーキテクチャ: ポートを中心に設計を組み立てる表現の一つ。概念は同じで、名称の表現の違いです。

ヘキサゴナルアーキテクチャの対義語・反対語

モノリシックアーキテクチャ: 全体が一体化しており、内部と外部の境界が薄い。外部との接続が直接的で、変更が広範囲に波及しやすい設計。
密結合アーキテクチャ: 部品間の結合度が高く、変更・再利用が難しい。外部の影響を受けやすく、保守性が低い。
直接結合アーキテクチャ: 外部システムやデータソースとポート/アダプターを介さず、直接結合している設計。拡張性やテストが難しくなる。
スパゲティアーキテクチャ: 依存関係が複雑に絡み合い、理解・保守が難しい。変更が他の部分に波及しやすい。
外部依存が強い設計: 外部のサービス・リソースに過度に依存し、内部ドメインの独立性が低い状態。
従来型レイヤードアーキテクチャ: 層間の依存が多く、境界が曖昧になることがあり、外部と内部の結合が強く感じられる場合がある。

ヘキサゴナルアーキテクチャの共起語

ポート: アプリケーションコアと外部世界をつなぐ入口・出口の抽象インターフェース。外部はこのポートを使ってコアとやりとりする。
アダプター: ポートの実装で、外部システムやUIなどと接続する具体的な接続部。ポートと外部の橋渡しとなる。
アプリケーションコア: ビジネスロジックとユースケースを中心に据えた中核部分。外部の具体的な技術に依存せず、ポートを通じてやりとりする。
ドメイン層: ドメインのビジネスルールを表現する層。エンティティや値オブジェクト、ドメインモデルを含む。
ドメインモデル: ドメインの概念とビジネスルールを表すオブジェクト群。エンティティや値オブジェクトを含む。
ユースケース: 外部からの要求を受けてアプリケーションが提供する機能の流れ。
アプリケーションサービス: ユースケースを組み合わせてビジネス処理を実行する中間層。
エンティティ: 識別子を持つドメインの実体。ライフサイクルと同一性を管理する。
値オブジェクト: 値として意味を持ち、等価性は値の組み合わせで判断される不変オブジェクト。
境界: 外部世界と内部を分ける節目。ポートやインターフェースを介して接続する。
インターフェース: ポートやアダプターの抽象。実装に依存せずに外部とやり取りする契約。
外部システム: データベース、外部API、UI、メッセージキューなど、アプリケーションの外側にある依存先。
プレゼンテーション層: ユーザー入力やAPIリクエストを扱う外部側の入口。
インフラストラクチャ: DB接続や外部ライブラリの実装を担い、アダプターが利用する実装を提供。
テスト容易性: ポートとアダプターの分離により、テストを行いやすくなる性質。
テストダブル: テスト時に用いるモック・スタブなどの代替実装。
依存性逆転の原則: 高レベルのモジュールが低レベルのモジュールに依存せず、抽象に依存する設計原則。
依存性注入: 依存関係を外部から注入して結合度を下げる技法。
低結合: モジュール間の結合を弱くして変更に強くする設計特性。
高結合を避ける設計: 内部と外部の依存を最小限にする工夫。
SOLID原則: 単一責任原則（SRP）、開放/閉鎖原則（OCP）、リスコ原則（LSP）、インターフェース分離の原則（ISP）、依存性逆転の原則（DIP）などの設計原則の総称。

ヘキサゴナルアーキテクチャの関連用語

ヘキサゴナルアーキテクチャ: ビジネスロジックを中心に据え、外部システムとの接続点をポートとアダプターという境界で分離する設計思想。内側のコアは安定しており、外側の変化に強い。
ポートとアダプター: ポートは内部と外部の境界に現れる公開インタフェース、アダプターはそのインタフェースを実装して外部システムとやり取りする部品。
内部コア / ドメインモデル: ビジネスルールの中心。エンティティ、値オブジェクト、集約などを含み、外部依存を持たない設計。
エンティティ: 一意の識別子を持つオブジェクト。長期的なライフサイクルと同一性が重要。
値オブジェクト: 不変で、値の組み合わせで意味を表すオブジェクト。等価性は値の組み合わせで判定。
集約: データの一貫性を保つ境界。集約ルートを介して内部の整合性を保つ。
リポジトリ: データの永続化を抽象化するインタフェース。ドメイン層からデータの取得・保存を行う窓口。
入力ポート: ユースケースを起動するための公開インタフェース。外部からの入力を受け付ける端口。
出力ポート: アプリケーションから外部へ結果を伝えるインタフェース。プレゼンテーションや外部通知の受け口。
アダプター: 外部システムとの接続を実装する部品。データベース、UI、メッセージングなどを担当。
入力アダプター: UIやAPIなどからポートへデータを渡す役割。コントローラーやCLIなどが該当。
出力アダプター: 出力ポートの実装を通じて外部へ結果を伝える。DB実装、ファイル出力、イベント送出など。
依存性逆転の原則（DIP）: 高レベルのモジュールが低レベルのモジュールに依存せず、抽象に依存することで柔軟性を確保する設計原則。
依存性逆転ルール: 内側の層は外側の層に依存せず、抽象を介してやり取りするという指針。
クリーンアーキテクチャ: 層間の依存性を内向きに保ち、中心のビジネスルールを外部の技術的関心事から守る設計思想。
ドメイン駆動設計（DDD）: 複雑なビジネス領域をモデル化する手法。エンティティ、値オブジェクト、集約、境界づけを重視。
ユースケース: ユーザーの意図を実現する業務処理の単位。ビジネスの機能を表現する。
アプリケーションサービス: ユースケースを実現するための実装。ドメインとポートの仲介役。
ドメインイベント: ドメイン内で重要な出来事を表す通知。イベント駆動の連携を促進。
イベントバス / メッセージング: ドメインイベントを他のアダプターやサービスへ配信する仕組み。
外部システム: データベース、キュー、外部API、ファイルシステムなどビジネス外部の資源。
データベース・リポジトリ実装: 具体的な永続化技術の実装。リポジトリインタフェースを実装してデータを保存・取得。
テストダブル: テスト時に使う代替オブジェクト。モック、スタブ、フェイク、スパイなど。
モック: 挙動を事前に指定して検証するダブル。
スタブ: 呼び出しに対して固定値を返すダブル。
フェイク: 実装は簡易だが実用的なダブル。
スパイ: 呼び出し履歴を検証するダブル。
境界 / Boundary: 内側と外側を分ける境界線。ポートとアダプターが接する場所を指すことが多い。
インフラストラクチャ層: データベース、ネットワーク、外部APIなど外部依存を実装する層。
ACL（Anti-Corruption Layer）: 外部システムのモデルが自分のドメインへ影響を及ぼさないよう、変換層を挟む設計技法。