はじめに
前回のpart4.1では、DIPとヘキサゴナルアーキテクチャの概要について紹介しました。前回でも書いたように、今回の記事ではヘキサゴナルアーキテクチャについてさらに詳しく説明していきます。
では、始めていきます。
ヘキサゴナルでのサービス指向のアプローチ
ヘキサゴナルアーキテクチャを生み出したチーム（SaaSOvationチーム）は、それ以前のレガシーなコラボレーションツールからの移行するためのサービスを作成するにあたり、ESB Muleという製品を導入しました。
ESB（エンタープライズサービスバス）とは
異なるアプリケーション間のリアルタイムのデータ交換をサポートするソフトウェアアーキテクチャパターンのこと。アプリケーションは関連データを ESB に渡し、ESB はそのデータを変換して、それを必要とする他のアプリケーションに転送する。
また、SOA（後述）の機能も搭載されている。
SOA（サービス指向アーキテクチャ）の導入
SOAは「Service Oriented Architecture」の略称です。ソフトウェアをサービスとして連携させ、システム全体を構築していきます。DDDの戦略的なビジネスサービスに従いつつ、連携内容に応じてSOAのサービス設計原則も意識しておくとよいとされています。
また、SOAでの設計原則として、Ed Thomasさんは以下の８つを挙げています。
- 1,標準化
- サービスの説明を契約（インターフェース）で示す
- 2,疎結合性
- 依存関係を減らし、サービス自身の依存情報を認識する
- 3,抽象性
- 契約（インターフェース）の公開だけで、内部実装は見せない
- 4,構成可能性
- 粒度の大きい（ひとつのサービスが幅広い機能やロジックを含む、まとまりの大きな単位で設計されている）サービスに組み込み可能で、制限がない
- 5,自立性
- サービスが一貫性と信頼性を持ち、独立して成立する
- 6,ステートレス性
- サービスの利用者側で状態を管理する
- 7,発見可能性
- サービスの情報をメタデータで記述し、他から発見できる
- 8,再利用性
- 他のサービスからも再利用できる。粒度のより粗いサービスの作成に利用できる
ブラウザで「SOA 設計原則」と調べると、今回紹介したような８つのものや１０個のものなどいろいろ出てきますが、本質的にはどれも同じようなものです。（おそらく）
サービス設計の指針としては、ビジネス戦略を示す「ビジネスサービス」とREST（後述）／メッセージ型といった「技術的サービス」の両面を意識します。さらにDDDでは「ユビキタス言語」や「境界づけられたコンテキスト」が不自然に分断されていないかをチェックすることで、より良いサービスを公開できます。
ヘキサゴナルで使用されるREST
DDDでWebサービスを構築するときによく利用される技術がRESTです。
RESTとは、（Representational State Transfer）の略で、これを直訳すると
このRESTに従ったサービスを「RESTful」と呼びます。以下の画像が特徴をわかりやすく解説しているので見てください。
この画像のないで述べられている４つのポイントについてそれぞれを詳しく解説します。
- 一位なURLでリソースを公開
- URIとは、「Uniform Resource Identifier」の略語であり、その訳の通りに提供する「リソース」を統一された（一意な）アドレスで表現することができます。
ここでいう「リソース」とは、手一驚するサービスの顧客やプロダクト、検索結果などを示します。 - ステートレスな通信
- 「ステートレスな通信」とは、セッションの状態を保持せず、各リクエストを独立して処理する通信方法で、これと対照的なものとして「ステートフルな通信」があります。前回リクエストの状態などを記憶しないため、各メッセージにはそのリクエストを処理するために必要な情報がすべて含まれています。
- GET、POST、PUT、DELETEといった標準化された命令体系
- RESTでは「GET（取得）」「POST（登録）」「PUT（登録または更新）」「DELETE（削除）」等のHTTPメソッドを用いてリソースを操作できます。これらの命令は標準的な振る舞いが決まっており、変更を伴わない安全な操作で、同じ処理を何回呼び出しても結果が変わらなず、問題も発生しない「冪（べき）等性」があります。
- ハイパーメディアによるリソース連携
- ハイパーメディアとは、簡単にいえばハイパーテキストの拡張版です。
まず、ハイパーテキストは、文書内に他の文書への参照を埋め込み、複数の文書を相互に結びつけたものです。次に、ハイパーメディアとは、マルチメディア要素でネットワークを構築するもので、ハイパーテキストと異なりテキスト要素に限定されるものではありません。
RESTでは、ハイパーメディアを用いて、レスポンスの中に他のリソース情報を埋め込むことができます。DDDでRESTの導入
RESTは疎結合で理解しやすい仕組みであるため、スケーラブルな（サービス利用後にその利用規模を増減させることができる）サービスの提供にも適しています。そのため、DDDのヘキサゴナルアーキテクチャとの相性も良いとされています。
なお、RESTで公開するインターフェースは、コアドメインをそのまま公開するのではなく、公開用の独自モデルを設計するか、ical(一般的なカレンダー形式)のようなメディア対応を使用することが推奨されています。おわりに
今回の記事では、ヘキサゴナルアーキテクチャについてより深く解説しました。次回はコマンドクエリ責務分離（CQRS）について解説します。
では、最後までお読みいただきありがとうございました。次回もよろしくお願いします。参考
「実践ドメイン駆動設計」から学ぶDDDの実装入門/青木 淳夫
実践DDD本 第4章「アーキテクチャ」 ～レイヤからヘキサゴナルへ～