Help us understand the problem. What is going on with this article?

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 img # 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 img # Book
Use Case Driven Object Modeling with UML: A Practical Approach
Kendall Rosenberg, Doug Scott (著)
2000/12/7 img # Book
Pattern-Oriented Software Architecture, A System of Patterns
Frank Buschmann (著), Regine Meunier (著), Hans Rohnert (著), Peter Sommerlad (著), Michael Stal (著)

#memo
1996年発行された書籍の改定版?
2001/11 img ユースケース入門―ユーザマニュアルからプログラムを作る (Object Technology Series)
ダグ ローゼンバーグ (著), ケンドール スコット (著), Doug Rosenberg (原著), Kendall Scott (原著), 長瀬 嘉秀 (翻訳), 今野 睦 (翻訳), テクノロジックアート (翻訳)

# memo
この書籍が ICONIX を日本に初めて紹介した
2003/8/22 img # Book
Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans (著)

# Memo
DDDの原点。
2005/04/01 img # Web
Hexagonal architecture (Archived)
Alistair, Cockburn

# Memo
Hexagonal Architecture についての最初の記事。本家は工事中(2020/03/10 現在)のため、アーカイブを参照のこと。
2007/x/x img # Book
Use Case Driven Object Modeling with UMLTheory and Practice
Theory and Practice
Authors: Rosenberg, Don, Stephens, Matt
2007/10/16 img # Book
ユースケース駆動開発実践ガイド
ダグ・ローゼンバーグ (著), マット・ステファン(著), 三河淳一 (翻訳), 佐藤竜一 (翻訳), 船木健児 (翻訳)

# memo
「ロバストネス分析」と「ICONIXプロセス」を使用したユースケース駆動開発について解説している。
2008/5/15 img # Book
Use Case Driven Object Modeling with UMLTheory and Practice
Don Rosenberg (著), Matt Stephens (著)
2008/7/29 img # Web
Tag Archives: onion architecture
Jeffrey Palermo

# memo
Onion architecture についての最初の記事。4つの記事からなる。
2011/4/8 img # Book
エリック・エヴァンスのドメイン駆動設計
Eric Evans (著), 和智右桂 (翻訳), 牧野祐子 (翻訳), 今関剛 (監修)

# memo
約8年を経て邦訳された Evans 本。
2012/8/13 img # Web
The Clean Architecture - The Clean Code Blog
by Robert C. Martin (Uncle Bob)

# memo
Clean Architecture のエッセンスについて記載されたWeb記事。最初に言及された記事。
2013/2/6 img # Book
Implementing Domain-Driven Design
Vaughn Vernon (著)

# memo
Evans 本に記載された DDD の概念を実装するための事例を紹介した書籍(?)
DDD に対し、 IDDD と表現されることが多い。
2013/10/1 img # Book
モデルベース要件定義テクニック
神崎善司 (著)
2015/3/16 img # 書籍
実践ドメイン駆動設計
ヴァーン・ヴァーノン (著), 高木正弘 (翻訳)

# memo
IDDD本の邦訳。
2015/10/05 img # 書籍
クリーンアーキテクチャ(The Clean Architecture翻訳) - blog.tai2.net

# memo
3年を経て翻訳された クリーンアーキテクチャ のWeb記事。
2015/10/09 img # Web
ヘキサゴナルアーキテクチャ - blog.tai2.net

# memo
10年を経て邦訳された ヘキサゴナルアーキテクチャ のWeb記事。
2017/9/12 img # Web
Clean Architecture: A Craftsman's Guide to Software Structure and Design
Robert C. Martin (著)

# memo
エッセンスのみのシンプルなWeb記事に対し、詳細な解説を盛り込んだ書籍。
2018/8/1 img # 書籍
Clean Architecture 達人に学ぶソフトウェアの構造と設計
Robert C.Martin (著), 角 征典 (著), 高木 正弘 (著)

用語

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

単語 意味
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" という節で以下の3つの図を用いて説明している。

image.png

image.png

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

image.png

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

img.jpg

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

項目 内容
名称 - ドメイン駆動設計
- DDD : Design-driven development
出典 原典:Domain-Driven Design: Tackling Complexity in the Heart of Software
日本語訳:エリック・エヴァンスのドメイン駆動設計
メモ 言わずもがな。20年経ったいまも色褪せない。
  • DDD Reference では "Pattern Language Overview" として下図が紹介されている。

image.png
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」 として表現されている。

image.png

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

image.png

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

image.png

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

image.png

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

image.png

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

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

img.jpg

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

項目 内容
名称 Onion Architecture
出典 原典:Tag Archives: onion architecture - Jeffrey Palermo
日本語訳:ない?
コード jeffreypalermo / onion-architecture — Bitbucket
メモ ヘキサゴナル・アーキテクチャと同じ思想を共有しながら、より実践的な内容に落とし込まれたアーキテクチャ。
伝統的な レイアードアーキテクチャとの比較や、 .NET などを例にしたクラス構成例があるため、実装に落とし込みやすそう。
IDDD本では、「ヘキサゴナルアーキテクチャを言い換えた残念なものにしか見えなかった」との言及があり、評価は分かれるみたい。
  • 原文中に、ヘキサゴナルアーキテクチャに対する言及がある。
    • 共有する前提として、「インフラストラクチャーの外部化」がある。
  • IoC コンテナを利用した具体的な実装方法の解説がある。
  • オニオンアーキテクチャを平坦化した記事をよく見るが、原文でもそのような図を用いて解説されている。
  • 原文の日本語訳はない?
  • (以下の図が紹介されているが、色が同系色過ぎて見づらい。)

image.png

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

image.png

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

img.jpg

img.jpg

img.jpg

img.jpg

  • 教義とされている以下の4つのポイントは非常に重要である。

オニオンアーキテクチャの主な教義:
- アプリケーションは、独立したオブジェクトモデルを中心に構築されます
- 内層はインターフェースを定義します。外層はインターフェースを実装します
- カップリングの方向は中心に向かっています
- すべてのアプリケーションコアコードは、インフラストラクチャとは別にコンパイルおよび実行できます。

  • Domain や Model 、 Application がどういう定義で使われているかは分からないが、「DDDパターンなしでも機能する」旨の記載がる。(Part.4)
  • ただし、用語としては、DDDの言葉と同義と捉えても問題なさそう。
  • 純粋に書き起こすと、ディレクトリ構成は下図のようになるはず。

img.jpg

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

項目 内容
名称 Clean Architecture
出典 原典:The Clean Architecture - The Clean Code Blog
日本語訳:クリーンアーキテクチャ - blog.tai2.net
  • 有名なのは以下の図

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

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

image.png

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

image.png

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

img.jpg

全体を通して

メモ

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

おわりに

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

参考

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした