本稿で紹介するアーキテクチャの種類
エバンズ本では、DDDのアーキテクチャは「レイヤアーキテクチャ」を中心に紹介していました。これに対してIDDD本では「ヘキサゴナルアーキテクチャ」を提唱しています。さらにヘキサゴナルアーキテクチャと関係が強い「サービス指向（SOA、REST）」「コマンドクエリ責務分離（CQRS）」「イベント駆動アーキテクチャ（パイプ＆フィルター、長期サーガ、イベントソーシング）」といった概念やアーキテクチャ方式についても取り上げています。
特定のアーキテクチャに依存しないDDD
DDDは特定の技術に依存していないため、自由にアーキテクチャを選択することができます。アーキテクチャの選定においては、構築するシステムに求められる「機能要求（ユースケース、ユーザーストーリー、ドメインモデルのシナリオ等）」と「品質要求（性能、エラー制御、SLA、リアルタイム性等）」が大きな判断材料となります。最適なアーキテクチャを選択することは、プロジェクト成功に向けて重要なポイントとなります。
SaaSOvationのCIOに聞くアーキテクチャーの変遷
それでは、適切なアーキテクチャを選択することが成功の秘訣であるというシナリオを見てみましょう。IDDD本のサンプルプロジェクトであるSaaSOvationチームのCIO（最高情報責任者）にインタビューした時のアーキテクチャの変遷は次の通りです。
| 順番 | 背景 | 選定アーキテクチャ | 詳細 |
|---|---|---|---|
| 1 | デスクトップアプリケーションとして初期開発 | レイヤアーキテクチャ | C／Sシステムのためクライアント用のアプリケーション層とDB層で構築 |
| 2 | SaaSモデルへの移行に加え、アドオン機能の複雑化 | レイヤアーキテクチャに「依存性逆転の原則（DIP）」を導入 | DIとユニットテストを導入し品質向上。ドメインに集中し、後にUI層や永続化層を入れ替え |
| 3 | スマホへの対応、認証やセキュリティの一元管理、管理ツール、BIツールなど多数の要望 | ヘキサゴナルアーキテクチャへの移行／RESTの導入 | ポート＆アダプターの手法により、NoSQL、メッセージングなどに対応できたことで新機能への要望に対応 |
| 4 | レガシーシステムのユーザーデータをクラウドへ移行するサービスの提供 | SOAの導入 | アプリケーション統合フレームワーク（ESB Mule）を用いてデータをサービスで集約 |
| 5 | ユーザー別の情報が表示されるダッシュボードの機能拡張 | CQRSの導入 | コマンド（入力）とクエリ（描画イベント）を分解して複雑なダッシュボードの表示が可能 |
| 6 | 時間がかかる処理のユーザーストレスやタイムアウトへの対応 | イベント駆動アーキテクチャの導入 | 「パイプ＆フィルター」パターンを導入 |
| 7 | 30億ドルで買収され、新ユーザー増加とシステム統合によりデータが爆発的に増加 | 分散変更処理への対応 | 「パイプ＆フィルター」を分散処理対応するため、「長期プロセス（サーガ）」を導入しインフラを改善 |
| 8 | 政府より法的な監査の要求 | イベントソーシングの導入 | ドメインモデルでの全ての変更内容を追跡することでコンプライアンス問題に対応 |
この表ではDDDを採用していたからこそ柔軟にアーキテクチャを拡張できるというストーリーを理解していただければと思います。上の表で紹介している順番に沿って、各アーキテクチャについて見ていきましょう。
レイヤからDIP、そしてヘキサゴナルへ
まず、大きな変化としては、（1）レイヤアーキテクチャ→（2）DIPに基づいたレイヤアーキテクチャ→（3）ヘキサゴナルアーキテクチャの変遷が挙げられます。
