Software Architecture - DDD と アーキテクチャ にまつわるエトセトラ

要約 / inb4 tl;dr

• DDD（ドメイン駆動設計）について調べ始めたら、解説記事でお腹いっぱいになった。
• 更に、一緒に語られるアーキテクチャも整理したい欲が出てきた。
  • Layered Architecture
  • Layered Architecture with DIP (Dependency inversion principle)
  • Hexagonal Architecture
  • Onion Architecture
  • Clean Architecture
• こういった経緯で、元になった書籍や記事をまとめてみた。
  • ちょっとしたまとめも書いた

はじめに

『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』 を読んで DDD入門をしてみて、ボトムアップで作り上げるときの アーキテクチャ に興味が湧き、今後、調べていくに当たって最初に見るべきであろう情報をまとめてみました。
言葉や単語として知ってはいても、手を動かして表現出来るほど理解出来ていないことが多いので、そこに繋げられるよう理解していきたいところです。

原典に当たれ

原典となる書籍やWebサイトのまとめ

原典となった（と思われる）書籍やWebサイトを下表にまとめました。

Year	Image	Article
1996/7/12		# Book Pattern-Oriented Software Architecture Volume 1: A System of Patterns by Frank Buschmann (12-Jul-1996) Hardcover # Memo Evans の DDD本 で Layered Architecture に関する Pattern にまつわる文脈で言及されている。
1999/3/15		# Book Use Case Driven Object Modeling with UML: A Practical Approach Kendall Rosenberg, Doug Scott (著)
2000/12/7		# Book Pattern-Oriented Software Architecture, A System of Patterns Frank Buschmann (著), Regine Meunier (著), Hans Rohnert (著), Peter Sommerlad (著), Michael Stal (著) #memo 1996年発行された書籍の改定版？
2001/11		ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series) ダグ ローゼンバーグ (著), ケンドール スコット (著), Doug Rosenberg (原著), Kendall Scott (原著), 長瀬 嘉秀 (翻訳), 今野 睦 (翻訳), テクノロジックアート (翻訳) # memo この書籍が ICONIX を日本に初めて紹介した
2003/8/22		# Book Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans (著) # Memo DDDの原点。
2005/04/01		# Web Hexagonal architecture (Archived) Alistair, Cockburn # Memo Hexagonal Architecture についての最初の記事。本家は工事中（2020/03/10 現在）のため、アーカイブを参照のこと。
2007/x/x		# Book Use Case Driven Object Modeling with UMLTheory and Practice Theory and Practice Authors: Rosenberg, Don, Stephens, Matt
2007/10/16		# Book ユースケース駆動開発実践ガイド ダグ・ローゼンバーグ (著), マット・ステファン(著), 三河淳一 (翻訳), 佐藤竜一 (翻訳), 船木健児 (翻訳) # memo 「ロバストネス分析」と「ICONIXプロセス」を使用したユースケース駆動開発について解説している。
2008/5/15		# Book Use Case Driven Object Modeling with UMLTheory and Practice Don Rosenberg (著), Matt Stephens (著)
2008/7/29		# Web Tag Archives: onion architecture Jeffrey Palermo # memo Onion architecture についての最初の記事。４つの記事からなる。
2011/4/8		# Book エリック・エヴァンスのドメイン駆動設計 Eric Evans (著), 和智右桂 (翻訳), 牧野祐子 (翻訳), 今関剛 (監修) # memo 約8年を経て邦訳された Evans 本。
2012/8/13		# Web The Clean Architecture - The Clean Code Blog by Robert C. Martin (Uncle Bob) # memo Clean Architecture のエッセンスについて記載されたWeb記事。最初に言及された記事。
2013/2/6		# Book Implementing Domain-Driven Design Vaughn Vernon (著) # memo Evans 本に記載された DDD の概念を実装するための事例を紹介した書籍（？） DDD に対し、 IDDD と表現されることが多い。
2013/10/1		# Book モデルベース要件定義テクニック 神崎善司 (著)
2015/3/16		# 書籍 実践ドメイン駆動設計 ヴァーン・ヴァーノン (著), 高木正弘 (翻訳) # memo IDDD本の邦訳。
2015/10/05		# 書籍 クリーンアーキテクチャ(The Clean Architecture翻訳) - blog.tai2.net # memo 3年を経て翻訳された クリーンアーキテクチャ のWeb記事。
2015/10/09		# Web ヘキサゴナルアーキテクチャ - blog.tai2.net # memo 10年を経て邦訳された ヘキサゴナルアーキテクチャ のWeb記事。
2017/9/12		# Web Clean Architecture: A Craftsman's Guide to Software Structure and Design Robert C. Martin (著) # memo エッセンスのみのシンプルなWeb記事に対し、詳細な解説を盛り込んだ書籍。
2018/8/1		# 書籍 Clean Architecture　達人に学ぶソフトウェアの構造と設計 Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ (著), 角 征典 (著), 高木 正弘 (著)

用語

部分的に単語もまとめてみました。

単語	意味
YAGNI	You ain't gonna need it 機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則 YAGNI - Wikipedia
ロバストネス分析	詳細設計の前に実施する予備設計 予備設計をすることによってシーケンス図やクラス図を作成するときに仕様の詳細について調べたり考えたりする時間を省略することができる。 ロバストネス図作成時に、ユースケース記述上の足りない観点や疑問点を洗い出し、完全なユースケース記述に近づけ ロバストネス分析の目的 - Qiita
ICONIXプロセス	ラショナル統一プロセス（RUP）、エクストリーム・プログラミング（XP）、及びアジャイルソフトウェア開発よりも前から存在するソフトウェア開発方法論 4ステップのプロセスでただ4つのUML図を使用して、ユースケース記述を動作するコードに変換する。 (ICONIX - Wikipedia](https://ja.wikipedia.org/wiki/ICONIX)
RUP	Rational Unified Process ラショナル統一プロセス (Rational Unified Process; RUP) とは、IBM社ラショナルブランドのオブジェクト指向型ソフトウェア開発プロセス、およびその製品のことを指す。 ラショナル統一プロセス - Wikipedia
オブジェクト指向分析／設計	OOAD ( object-oriented analysis and design ) ソフトウェア工学において、ソフトウェア (システム) を相互作用するオブジェクトの集まりとしてモデル化 (オブジェクト指向モデリング) する、オブジェクト指向に基づくソフトウェア開発の方法である。 Cite From: オブジェクト指向分析設計 - Wikipedia
ドメインモデリング	システムに関わるさまざまな実体とそれらの関係を説明するシステムの概念モデルである。 システムの鍵となる概念と用語を文書化するために作成される。 システムの主要な実体とそれらの間の関係を明らかにし、一般にそれらの重要なメソッドと属性も洗い出す。 ドメインモデル - Wikipedia
DTSTTCPW	Do The Simplest Thing That Could Possibly Work Do The Simplest Thing That Could Possibly Work
TDD	Test Driven Development テスト駆動開発
DDT	Design Development Test 設計駆動テスト
プラガブル	（プラグで）接続可能な pluggableの意味・使い方・読み方
イテレーション	反復、繰り返しという意味の英単語。 イテレーション（イテレート）とは - IT用語辞典 e-Words
CASEツール	computer aided software engineering / ケース / コンピュータ支援ソフトウェア工学 ソフトウェアライフサイクル・プロセス（分析・設計・開発・保守）を支援するツールの総称 対応するプロセスに応じて、上流CASEツール（分析・設計など）、下流CASEツール（開発・テストなど）、保守CASEツール（リエンジニアリングなど）に大別される。 CASE（しーえいえすいー） - ITmedia エンタープライズ
Booch法	1990年頃にグラディ・ブーチによって開発されたオブジェクト指向ソフトウェア開発方法論のこと。 『Booch法:オブジェクト指向分析と設計』 (原著初版は1991年刊、原著第2版は1993年刊、第2版日本語訳は1995年刊) でBooch法が説明されている Booch法の記法は UML の起源の一つである Booch法 - Wikipedia
OMT	オブジェクトモデル化技法 (Object Modeling Technique) オブジェクト指向ソフトウェア開発方法論であり、1990年頃にジェームズ・ランボー、マイケル・ブラハ、ウィリアム・プレメラニ、フレデリック・エディ、ウィリアム・ローレンセンなどの人々によって開発された。 オブジェクトモデル化技法 - Wikipedia
Objectory	Objectoryは、主にオブジェクト指向ソフトウェアエンジニアリングに大きく貢献したIvar Jacobsonによって作成されたオブジェクト指向の方法論 Objectory - Wikipedia

まとめてみた感想

• Layered Architecture に関する代表的な書籍や記事は見つからなかった。
  • 2000年の段階で経験的に構築され、デファクト・スタンダードになっていた模様。
    • 次の2つがまずは参考になりそう。
    • 書籍： Pattern-Oriented Software Architecture, A System of Patterns
    • 書籍： エリック・エヴァンスのドメイン駆動設計
• Clean Architecture の書籍が出たのが思っていたより最近だった。
• パターンやソフトウェアアーキテクチャ、特に Layered Architecture をベースとした考えがまとまってきたのが、思ったより最近（2000年頃）だった（ように見える）。
  • 2000年より前は、アプリケーションというよりも、広い意味でのソフトウェアの文脈（ネットワークやサーバ構成含む）で語られていた？
    • 「Pattern-Oriented Software Architecture, A System of Patterns」では、 Layered な代表例として OSI参照モデルの例が出てくる。

個人的な気付き

レイヤードアーキテクチャ / Layered Architecture

項目	内容
名称	- レイヤードアーキテクチャ - レイヤー化アーキテクチャ - Layered Architecture
出典	原典：ない？ 日本語訳：ない？
メモ	経験的に構築された概念であり、ソフトウェア開発の文脈において明確に定義している著名な文献は存在しない？

• "Pattern-Oriented Software Architecture, A System of Patterns (Aug. 2000)" では、 "Architectual Patterns" の中で、 "Layers" という節で以下の３つの図を用いて説明している。

• "Domain-Driven Design: Tackling Complexity in the Heart of Software (Aug. 2003)" では、"Layered Architecture" として以下の図を用いて説明している。（図は邦訳版）

• 純粋に書き起こすと、ディレクトリ構成は下図のようになるはず。

ドメイン駆動設計 / DDD : Design-driven development

項目	内容
名称	- ドメイン駆動設計 - DDD : Design-driven development
出典	原典：Domain-Driven Design: Tackling Complexity in the Heart of Software 日本語訳：エリック・エヴァンスのドメイン駆動設計
メモ	言わずもがな。20年経ったいまも色褪せない。

• DDD Reference では "Pattern Language Overview" として下図が紹介されている。

Pattern Language Overview - Domain-Driven Design
Definitions and Pattern Summaries by Eric Evans Domain Language, Inc.
Microsoft Word - pdf version of final doc - Mar 2015.docx

• DDD Reference には DDDのエッセンスが詰まっていそう。

ヘキサゴナル・アーキテクチャ / Hexagonal architecture

項目	内容
名称	- Hexagonal architecture - Ports & Adapter - Ports and Adapters
出典	原典：Alistair.Cockburn.us - Hexagonal architecture 日本語訳：ヘキサゴナルアーキテクチャ - blog.tai2.net
メモ	『 Ports and Adapters 』は、業務系や大規模なシステムにおいて、保守性（拡張性やテスト容易性）を確保するために、アプリケーションとそれ以外を接続する Port と Adapter という概念を示した。 FIT と呼ばれるコードサンプルも紹介されているが、汎用的に使用できるものではなかったようにみえる。

• 「ヘキサゴナル・アーキテクチャ」の「ヘキサゴナル（六角）」にあまり意味はない。
• 『 Ports and Adapters 』の方がアーキテクチャの意図を上手く表している。
• 下図のうち、「Application」を取り巻く 「黒い六角形の線」 も、実は重要な意味を持っている。
• 「黒い六角形の線」は、 「Use Case Boundary」 として表現されている。

• 上の図は、以下のように、「１つのポートに、複数のアダプターが存在する」ことを意味している。
• つまり、「Use Case Boundary」には、複数のポートが存在し、ポートは、六角形の一辺で表されている。

• また、構成要素全体の関係は下図のようになっている（ようだ）。

• 個人的には、以下のような図の方が分かりやすい。

• 全体を通して、概念や意図は共感するが、実装イメージが付きづらい。
• なお、IDDD本（実践ドメイン駆動設計 - ヴァーン・ヴァーノン）には以下のような図があり、本文中でも「ヘキサゴナルアーキテクチャ」という単語が頻出する。

実践ドメイン駆動設計 - ヴァーン・ヴァーノン (著), 高木正弘 (翻訳)

• 純粋に書き起こすと、ディレクトリ構成は下図のようになるはず。

オニオン・アーキテクチャ / Onion Architecture

項目	内容
名称	Onion Architecture
出典	原典：Tag Archives: onion architecture - Jeffrey Palermo 日本語訳：ない？
コード	jeffreypalermo / onion-architecture — Bitbucket
メモ	ヘキサゴナル・アーキテクチャと同じ思想を共有しながら、より実践的な内容に落とし込まれたアーキテクチャ。 伝統的な レイアードアーキテクチャとの比較や、 .NET などを例にしたクラス構成例があるため、実装に落とし込みやすそう。 IDDD本では、「ヘキサゴナルアーキテクチャを言い換えた残念なものにしか見えなかった」との言及があり、評価は分かれるみたい。

• 原文中に、ヘキサゴナルアーキテクチャに対する言及がある。
  • 共有する前提として、「インフラストラクチャーの外部化」がある。
• IoC コンテナを利用した具体的な実装方法の解説がある。
• オニオンアーキテクチャを平坦化した記事をよく見るが、原文でもそのような図を用いて解説されている。
• 原文の日本語訳はない？
• （以下の図が紹介されているが、色が同系色過ぎて見づらい。）

• 意図が分かりやすいように図を作ると下図のようになった。

• 上記の感じで、掲載されていた図を色分けしながら再作成した。

• 教義とされている以下の４つのポイントは非常に重要である。
  • 特に４つ目の、 『すべてのアプリケーションコアコードは、インフラストラクチャとは別にコンパイルおよび実行できます』 はとても大きな気付きだった。
    • 成瀬さんがなせ、『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』の中で、インフラのコードを別けていたのか、これで理解できた気がする。

オニオンアーキテクチャの主な教義：

• アプリケーションは、独立したオブジェクトモデルを中心に構築されます

• 内層はインターフェースを定義します。外層はインターフェースを実装します

• カップリングの方向は中心に向かっています

• すべてのアプリケーションコアコードは、インフラストラクチャとは別にコンパイルおよび実行できます。

• Domain や Model 、 Application がどういう定義で使われているかは分からないが、「DDDパターンなしでも機能する」旨の記載がる。（Part.4）

• ただし、用語としては、DDDの言葉と同義と捉えても問題なさそう。

• 純粋に書き起こすと、ディレクトリ構成は下図のようになるはず。

クリーン・アーキテクチャ / Clean Architecture

項目	内容
名称	Clean Architecture
出典	原典：The Clean Architecture - The Clean Code Blog 日本語訳：クリーンアーキテクチャ - blog.tai2.net

• 有名なのは以下の図

引用：The Clean Architecture 13 August 2012 - Clean Coder Blog
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

• 書籍には以下の図も紹介されている。

• 上の２つの図は関連して捉えることができ、色分けすると下図のようになる。

• 純粋に書き起こすと、ディレクトリ構成は下図のようになるはず。

全体を通して

• DDDや各種アーキテクチャの採用は、中規模以上のシステムにおいて有効であり、簡単なWebアプリ開発での採用は足を遅くするだけ。
  • 「中規模」の定義は、、、？
    • LPサイトや単発のシステムは不要かもしれない。
    • 簡単な便利ツールも恐らく不要。
    • 数年単位で運用され、システム拡張が頻繁に行われそうなものは採用した方が良い。
    • ビジネスアプリケーションは言わずもがな（採用した方が良い）。
• 「DDD で取り敢えず作ってみる」なら、「オニオンアーキテクチャ」と「クリーンアーキテクチャ」が良さそう。
  • オニオンアーキテクチャ
    • ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本
      • →この書籍を一番最初にやるとボトムアップ（コード）から分かるので良い。
      • →手前味噌：Laravel - 『ドメイン駆動設計入門』を読んで Laravel を使って実装してみた - Qiita
    • [DDD]ドメイン駆動 + オニオンアーキテクチャ概略 - Qiita
    • ドメイン駆動設計 モデリング/実装ガイド - little-hands - BOOTH
  • クリーンアーキテクチャ：
    • 実装クリーンアーキテクチャ
    • 実践クリーンアーキテクチャ

メモ

• どのような時代背景からこれらのアーキテクチャが生まれてきたかが理解できると、それぞれのアーキテクチャの意図や目指すところがより理解出来そう。

おわりに

• 「オニオンアーキテクチャ」と「レイヤードアーキテクチャ」の詰めが甘いので、もう少し調べて増強する予定。

参考

• DDDからみた基盤となるアーキテクチャ • masu-mi's blog(Dirty Cache)
• Laravel - 『ドメイン駆動設計入門』してみて Clean な世界を垣間見た話し - Qiita