実はけっこう多い DDDの本

DDDの本と言っても、青い本、赤い本だけではなく実はいろいろある。用途や時代、知識や技術レベルに合う本を選んで時間を有効に使いたい[^waste_of_time]。

## 書籍・資料
以下に DDDの関連本を簡単に紹介し[^other_books]、その後で各書籍が触れているパターンについて表にまとめる。書籍のフルネームは意外と長いのでよく使われる呼び名や略称をタイトルとし、また表の列名に使うため2文字の記号も付与した。

### 初期のDDD本たち
DDD が出てきた00年代中盤はこんな感じだった。
- DB といえばほぼ RDB一択[^db]で、オンプレで SoR を開発していた。
- オブジェクト指向を熱心に信奉し手続き型勢を啓蒙したいと考える人が多かった。[^oo] 
- UML 普及期[^uml2]で、成果物にUMLの各種ダイアグラムを含める事が流行り始めた。[^uml1]
- XML 大全盛で、設定ファイルから Webサービスまで何でも XMLだった[^xml]。
- WF への倦怠に伴い反復漸進型[^I_and_I]開発への期待も高まってきたが、かと言ってすぐにアジャイルでもなく、メソドロジー論争からの流れで UP などの権威がまだ高かった[^unified_process]。[^xp_scrum]
[^I_and_I]: I&I (Iterative and Incrimental) process。Alistair Cockburn によれば Incremental = "add onto", Iterative = "alter" である。
[^xp_scrum]: ちなみにアジャイルといっても、当時はスクラムじゃなくXP[^XP]が本命だった。

#### エバンス本 (2003[^ddd2003]): D3[^ddd]
PoEAA で予告され[^PeEAA]満を持して登場した大古典。以後の関連書籍や言説の量から客観的に見ても歴史的インパクトはとても大きいが、決して読みやすい本ではなく多くのDDD難民を生み出した。
[^ddd]: 俗に言うエバンス本、または青い本。正式には 『Domain-Driven Design: Tackling Complexity in the Heart of Software』。
[^PeEAA]: Domain Model パターンの解説で、執筆中であると言及されていた。
[^XP]: 個人的には、今でもどちらかというとスクラムより XP が好ましい。

#### DDD Quickly (2006): DQ[^DDDQ]
エバンス本を要約した電子書籍でInfoQ でダウンロードできる。これで救われた DDD難民も当時は結構いたらしい[^DDDQ2]。『Secure By Design』では、まずこれを読むよう勧めている。
[^DDDQ]: 正式には 『Domain Driven Design Quickly』 (Abel Avram & Floyd Marinescu, 2006)
[^DDDQ2]: 国内だと、オージス総研/オブジェクトの広場の「[DDD難民に捧げるDomain-Driven Designのエッセンス](https://www.ogis-ri.co.jp/otc/hiroba/technical/DDDEssence/)」もよく読まれた

### 近現代のDDD本たち
エバンス本から10年後の2013年から現代までの本。この間、以下のようなことがあった。
- NoSQLブーム以降、RDBが数ある選択肢のうちの一つになった[^databases]
- クラウド技術やコンテナ技術が現れ、ほぼ大前提のレベルにまで普及した
- 世俗の開発でも関数型プログラミングが普及した[^academic_fp]
- リアクティブ、イベント駆動の概念・製品・技術が発達した
- マイクロサービス、サーバーレスが普及した [^shared_db]
- アジャイルが普及し、ドメインエキスパートまで含めたチーム一丸で協働しながら、小さなステップで反復開発するスタイルが一般的になった

#### IDDD (2013): ID[^IDDD]
エバンス本からこの IDDDまでの10年くらいで、ドメインを理解するにもモデル化するにも、**イベント**に着目すると良い事が知られてきた。この IDDD 以降、Domain Event が DDDのパターンカタログに追加された。ちなみに著者の Vaughn Vernon はリアクティブ周辺にも強い人で、『Reactive Messaging Patterns』でも Domain Event について説明している。
[^IDDD]: 正式には 『Implementing Domain-Driven Design』 (Vaughn Vernon, 2013)

#### DDD Reference (2015): RF[^DDDR]
Evans 自身が 12年分の知見を加味しつつ、青い本から DDD 要点を抜粋したカタログ。45のパターンが各 1ページ程度でまとめられ、非常に薄い[^DDDR2]。後発の DDD本からも参照されることが多い。
[^DDDR]: 正式には 『Domain-­Driven Design Reference』 (Evans Eric, 2015)
[^DDDR2]: 極限まで短くなっている分抽象度が高いので、必ずしも簡単とは言えないが、個人的には青い本を1回読むより、これを10回読むほうが短時間で多くの知見が得られると思う。

#### PPP of DDD (2015): PD[^PPPD]
『Secure By Design』でも DDD理解の参考図書として推奨されている良書。現代DDDをよく説明している。LDDD からも参照あり。
[^PPPD]: 正式には 『Patterns, Principles, and Practices of Domain-Driven Design』 (Scott Millett & Nick Tune, 2015)

#### DDD Distilled (2016): DD[^DDDD]
IDDD の著者 Vaughn Vernon の別の DDD 本。IDDD よりかなり短いが、かといって抽象的すぎることもなく、図を多用して分かりやすく説明している。ちなみに 'distill' は DDD 用語としても頻出で、『Secure By Design』でも詳しく説明されている。
[^DDDD]: 正式には 『Domain-Driven Design Distilled』 (Vaughn Vernon, 2016)

#### LDDD (2021): LD[^LDDD]
BoundedContext や Subdomain 周りのパターンが原型をくずさない範囲で明確に整理された[^LDDD2]。これにより、どの状況でどのパターンを使うかの判断フローが明確になり、実用性が格段に高まった。2020年代に DDD を実践する場合に考慮すべきことが、ほぼ抜かりなく解説されている。
[^LDDD]: 正式には 『Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy』 (Vlad Khononov, 2021)
[^LDDD2]: Core Domain が Core Subdomainになったり、Bounded Context を関連付けるパターン群が階層化されたり。

### DDD周辺の本たち
DDD 専門の本ではないが深く関連する分野の本たち。セキュリティ、関数型パラダイム、マイクロサービスの観点で選んでみた。

#### Secure By Design (2019): SD[^SBD]
セキュリティの本だが、著者たち全員が最も影響をうけたものとしてDDDを挙げており、第3章の概説をはじめとして驚くほど DDD 関連の記述が多い。セキュリティの CIA-Tのなかでも I(Integrity) に特に関係が深い[^integrity]。
[^SBD]: 『Secure By Design』 (Daniel Sawano, Dan Bergh Johnssonなど 2019)

#### Domain Modeling Made Functional (2018): DF[^DMMF]
実用上の選択肢がオブジェクト指向しかなかった時代と違い、関数型パラダイムでドメインを理解し[^functional_domain]モデル化することも身近になってきた。この本では第1章の 'Introducing Domain Driven Design' から始まり、以降の章でも DDD と FP の親和性の高さが随所で解説されている。
[^DMMF]: 正式には 『Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#』 (Scott Wlaschin, 2018)

#### Microservice Patterns (2018): MP[^MSP]
マイクロサービスのパターン本。サービス境界の問題や[^microservices_patterns]、イベント/メッセージングに関連して、DDD 関係の記述が多い。
[^MSP]: 正式には 『Microservices Patterns: With examples in Java』 (Chris Richardson, 2018)

#### Monolith to Microservices (2019): MM[^M2M]
マイクロサービスの大家である Sam Newman の本。DDD 関連のページ数は多くないが、マイクロサービスを開発するにあたって最低限知っておくべき DDD の核心を挙げているのが面白い。 
[^M2M]: 正式には 『Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith』 (Sam Newman, 2019)

 
## パターン
- 行方向にパターンを並べる。DDD Reference の順序とカテゴリ分けを用いた。
- 列方向に本（上で付与した2文字の記号）を並べる。
- ◎ 目次レベルで記載あり、○文中で説明あり、△ほぼ名称が登場するのみ

|Putting the Model to Work                    |D3    |DQ    |Rf    |ID    |PD    |DD    |LD    |SD    |DF    |MP    |MM    |
|---                                          |:-:   |:-:   |:-:   |:-:   |:-:   |:-:   |:-:   |:-:   |:-:   |:-:   |:-:   |
|Bounded Context[^bounded_context]            | ○    |   ◎  | ◎    | ◎    | ◎    | ◎    | ◎    | ◎    | ◎    | ○    | ◎    | 
|Ubiquitous Language[^ubiquitous_language]    | ○    |   ◎  | ◎    | ○    | ◎    | ◎    | ◎    | ○    | ◎    | ○    |      | 
|Continuous Integration                       | ○    |   ◎  | ◎    | △    | △    | △    |      |      |      | △    |      | 
|Model-Driven Design                          | ○    |   ◎  | ◎    |      | ◎    |      |      |      |      |      |      | 
|Hands-on Modelers                            | ○    |      | ◎    |      |      |      |      |      |      |      |      | 
|Refactoring Toward Deeper Insight            | ◎    |  ◎   | ◎    | △    | △    | △    |      |      | △    | △    |      | 
|**Building Blocks** [^building_blocks]       |**D3**|**DQ**|**Rf**|**ID**|**PD**|**DD**|**LD**|**SD**|**DF**|**MP**|**MM**|
|Layered Architecture[^layered_architecture]  | ○    |   ◎  | ◎    | ○    | ○    |      | ◎    |      |  △   |  ○   |      | 
|Entities                                     | ○    |   ◎  | ◎    | ◎    | ◎    | ○    | ○    |   ◎  |  ○   |  ○   |      | 
|Value Objects                                | ○    |   ◎  | ◎    | ◎    | ◎    | ○    | ○    |   ○  |  ○   |  ○   |      | 
|Domain Events                                |      |      | ◎    | ◎    | ◎    | ◎    | ○    |      |  ◎   |  ◎   |   ○  | 
|Services[^domain_service]                    | ○    |   ◎  | ◎    | ◎    | ◎    |      | ○    |      |      |  ○   |      | 
|Modules                                      | ○    |   ◎  | ◎    | ◎    | ○    | △    |      |      |      |      |      | 
|Aggregates                                   | ○    |   ◎  | ◎    | ◎    | ◎    | ◎    | ○    | ○    |  ○   |  ◎   | ◎    | 
|Repositories                                 | ○    |   ◎  | ◎    | ◎    | ◎    |      |      |   △  |  △   |  ○   |      | 
|Factories                                    | ○    |   ◎  | ◎    | ◎    | ◎    |      |      |      |      |  ○   |      | 
|Smart UI                                     | ○    |      |      | ○    |      |      |      |      |      |      |      | 
|**Supple Design**[^supple_design]           |**D3**|**DQ**|**Rf**|**ID**|**PD**|**DD**|**LD**|**SD**|**DF**|**MP**|**MM**|
|Intention-Revealing Interfaces               |   ○  |      | ◎    |   ○  |      |      |      |      |      |      |      | 
|Side-Effect-Free Functions                   |   ○  |      | ◎    |   ○  | △    |      |      |      |      |      |      | 
|Assertions                                   |   ○  |      | ◎    |   ○  | ○    |      |      |      |      |      |      | 
|Standalone Classes                           |   ○  |      | ◎    |      |      |      |      |      |      |      |      | 
|Closure of Operations                        |   ○  |      | ◎    |   △  | △    |      |      |      |      |      |      | 
|Declarative Design                           |   ○  |      | ◎    |   △  |      |      |      |      |      |      |      | 
|Drawing on Established Formalisms            |   ○  |      | ◎    |      |      |      |      |      |      |      |      | 
|Conceptual Contours                          |   ○  |      | ◎    |      |      |      |      |      |      |      |      | 
|**Context Mapping**[^strategic_design]       |**D3**|**DQ**|**Rf**|**ID**|**PD**|**DD**|**LD**|**SD**|**DF**|**MP**|**MM**|
|Context Map[^context_map]                    | ○    | ◎    | ◎    | ◎    | ◎    | ◎    | ○    | ◎    | ○    |      |      | 
|Partnership[^partner_ship]                   |      |      |   ◎  | ○    | ○    | ○    | ○    |      |      |      |      | 
|Shared Kernel                                | ○    | ◎    | ◎    | ○    | ○    | ○    | ○    |      | ○    |      |      |     
|Customer/Supplier                            | ○    | ◎    | ◎    | ○    | ○    | ○    | ◎    |      | ○    |      |      |     
|Conformist                                   | ○    | ◎    | ◎    | ○    | ○    | ○    | ○    |      | ○    |      |      |     
|Anticorruption Layer                         | ○    | ◎    | ◎    | ○    | ○    | ○    | ○    |      | ◎    |      |      |     
|Open-host Service                            | ○    | ◎    | ◎    | ○    | ○    | ○    | ○    |      |      |      |      | 
|Published Language                           | ○    |      |   ◎  | ○    | ○    | ○    | ○    |      |      |      |      | 
|Separate Ways                                | ○    | ◎    | ◎    | ○    | ○    | ○    | ◎    |      |      |      |      | 
|Big Ball of Mud[^big_ball_of_bud]            |      |      |   ◎  | ○    | ○    | ○    |      |      | △    |      |      | 
|**Distillation**                             |**D3**|**DQ**|**Rf**|**ID**|**PD**|**DD**|**LD**|**SD**|**DF**|**MP**|**MM**|
|Core Domain[^core_domain]                    | ○    |    ○ |    ◎ |  ○   |  ◎   |  ○   |  ○   |      |  ○   |  △   |      | 
|Generic Subdomains                           | ○    |    ○ |    ◎ |  ○   |  ○   |  ○   |  ○   |      |  ○   |  △   |      | 
|Supporting Subdomain[^supporting_subdomain]  | △    |      |[^ssd]| ○    |  ○   |  ○   |  ○   |      |  ○   |  △   |      | 
|Domain Vision Statement                      | ○    |      |    ◎ |      |  ○   |      |      |      |      |      |      | 
|Highlighted Core                             | ○    |      |    ◎ |      |      |      |      |      |      |      |      | 
|Cohesive Mechanisms                          | ○    |      |    ◎ |      |      |      |      |      |      |      |      | 
|Segregated Core                              | ○    |      |    ◎ |   ○  |      |   -  |      |      |      |      |      | 
|Abstract Core                                | ○    |      |    ◎ |      |      |      |      |      |      |      |      | 
|**Large-Scale Structure**                    |**D3**|**DQ**|**Rf**|**ID**|**PD**|**DD**|**LD**|**SD**|**DF**|**MP**|**MM**|
|Evolving Order[^evolving_order]              |   ○  |      |   ◎  |  △   |      |      |      |      |      |      |      | 
|System Metaphor[^system_metaphor]            |   ○  |      |   ◎  |      |      |      |      |      |      |      |      | 
|Responsibility Layers                        |   ○  |      |   ◎  |      |  ○   |      |      |      |      |      |      | 
|Knowledge Level[^knowledge_level]            |   ○  |      |   ◎  |      |      |      |      |      |      |      |      | 
|Pluggable Component Framework                |   ○  |      |   ◎  |      |      |      |      |      |      |      |      | 
|**DDD 外の参考概念**                         |**D3**|**DQ**|**Rf**|**ID**|**PD**|**DD**|**LD**|**SD**|**DF**|**MP**|**MM**|
|Event Sourced Domain Model[^aes]             |      |      |      | ○    |  ○   |      | ◎    |      |      |  ○   |      | 
|Domain Model (pattern)                       |      |      |      |      |  ○   |      | ◎    |      |      |  ◎   |      | 
|Active Record                                |      |      |      | ○    |      |      | ◎    |      |      |      |      | 
|Transaction Script                           |      |      |      | ○    |      |      | ◎    |      |      |  ◎   |      | 
|Anemic Domain Model[^anemiec_and_functional] |      |      |      | ○    |  ○   |      |      |      |  ○   |      |      | 
|Event Storming                               |      |      |      |      |  ○   |  ○   |      |      |  ◎   |  ○   |  ◎   | 
|Event Sourcing                               |      |      |      | ◎    |  ◎   |  ○   | ◎    |      |  ◎   |  ◎   |  △   | 
|CQRS                                         |      |      |      | ◎    |  ◎   |  ○   | ◎    |      |  ◎   |  ◎   |      | 
|Saga                                         |      |      |      | ○    |      |      | ○    |      |  ○   |  ◎   |  ◎   | 
|Process Manager[^process_manager]            |      |      |      |      |      |      | ○    |      |  ○   |      |      | 
|Microservice[^microservice]                  |      |      |      |      |  △   |      | ◎    |   ◎  |  △   |  ◎   |  ◎   | 
|Port & Adapter                               |      |      |  ○   | ○    |  ○   |  ○   | ○    |      |  ○   |  ○   |      | 
|Application Service[^application_service]    |      |      |      | ◎    |  ◎   |      |      |      |      |  △   |      | 
|Strangler Fig                                |      |      |      |      |      |      | ○    |      |      |  ○   |  ◎   | 

[^aes]: ここでは Learning DDD の用語の Event Sourced Domain Model とした。Implementing DDD では A+ES、Microservice Patterns では event-sourcing based aggregate と言っている。
[^ssd]: DDD Reference にないが、Subdomain の分類は Core, Generic, Supporting の３つ（あるいは Generic & Supporting を含めて４つ）とするのが今では一般的なのでこの位置に書いた

## パターン・カテゴリごとの寸評
### Putting the Model to Work
- 当然ながらどの本でも Bounded Context が最重要扱い[^ubiquitous_language_pddd]。
- 次いで Ubiquitous Languageで、DDD の本では昔も今も最重要レベル。上に挙げた DDD周辺本ではやや扱いが弱い。
- Model-Driven Design は、DDD Reference の図でも Building Blocks 群と BC/UL を結ぶ位置に置かれ、本来とても重要なパターンだが、言及は意外と少ない。
- Refactoring Toward Deeper Insight はほそぼそと触れられている。セキュアバイデザインでは「deep[^philosophy]」という概念から深く解説されている。
- Hand-on Modeler / Continuous Integration は最近はあまり触れられなくなった（すでに言うまでもないということかもしれない）。
[^ubiquitous_language_pddd]: Ubiquitous Language の開発こそ DDD と言われることもあるが、これとて Bounded Context 無しには成立しない。

### Building Blocks
- 特に重要なのは Aggregateで、『Monolith to Microservices』では 最低限知っておくべき DDDの事として、Bounded Context と共に挙げられる。関数型の場合には若干扱いが異なるが、DMMF や PPPD ではその点についても解説される。
- 次に重要なのが Domain Event で、モダンなDDD本はもちろん、DMMF やマイクロサービス本でも手厚く解説される。この Domain Event の有無が、古い DDDとモダンな DDDの最も顕著な違いでもある[^domain-event2]。
[^domain-event2]: 『From Object to Function』という関数型ドメインモデリングの本でも、DDD について言及しているのは、イベントに着目したドメインモデリングを二章に渡って解説してる部分だった。そこでも Aggregate と Domain Event にコマンドを加えた道具立てで、「状態」の変化について語っている。

### Supple Design
PPP of DDD くらいまでは若干記述があったが、最近の本ではあまり触れられない。このカテゴリは実はFPに関係が深く[^supple_design]、単発のネット記事などではたまに触れられるが、今回調べた DMMF では特に触れられていない[^dmmf_and_fp]。
[^dmmf_and_fp]: Supple Design のパターン群と特に親和性があるのは表示的意味論ベースのFPである一方、DMMF では微妙にテイストが違うという差かもしれない。

### Context Mapping
- DDD の最重要要素である BoundedContext 群の協調や統合に関わるカテゴリなので、古いDDD本でもモダンなDDD本でもまんべんなくカバーされている。
- 特に LDDD ではパターン群が階層的に整理され、初期のDDD本たちとは明確性や納得感に雲泥の差がある。
- BoundedContext と関連が強いマイクロサービスの関連本でもっと触れられても良さそうだが、意外と記述がない。

### Distillation[^distillation]
- このカテゴリでは Core / Generic / Supporting の3つの subdomain がよく言及される。DDD Reference では Supporting Subdomain が入っていなかったが、定番の 3タイプなので表に含めた。これらの記述も LDDD で特に手厚く、基本的な考え方から３タイプ間の移行まで詳しく解説される。
- その他は、実務上は知らなくてもあまり困らないかもしれない。

### Large-Scale Structure
- このカテゴリは、エバンス自身の本を除いてはあまり触れられていない。
- とはいえ、DDDの外から借用された Knowledge Level や System Metaphor あたりは、とても有名なので知っておくとよさそう。

### DDD 外の参考概念
- DDD Reference 所収のパターンではないが、DDDに関連が深いパターンやキーワードをいくつか抜き出した。
- Event Sourced Domain Model（ESDM）から Transaction Script（TS）のあたり: PoEAA では Domain Model(DM) と Transaction Script の2パターンが紹介されていたが、LDDD では更に ESDM と Active Record（AS）を含めた４つの選択肢として再整理された。これに伴い、長らくアンチパターン扱い[^transaction_script]だった TS が設計判断の決定木の中で復権し、一方 DM も「サブドメインタイプ＝Core」かつ「変更履歴が不要なケース」の条件下のただの選択肢になった。
- Event Storming から Process Managerあたり: Domain Event が DDD に含まれたことに伴い、イベント関連の概念についての言及も増えた。EDAの実装技法にとどまらず、Event Storming に見られるようにドメイン理解やコミュニケーションの面でも影響が大きい。
- Microservice その他のパターン群: サービス粒度の問題に BoudedContext/Aggregate が強く関連することから、Microservice 関連のパターンがよく言及される。アーキテクチャの層に関連する Onion, Hexagonal, Clean[^clean_architecture] は Port & Adapter として一括した。 
[^transaction_script]: もともと PoEAA では、メリデメや使える場面なども含めて記述されたパターンの一つであり、無条件にアンチパターンとされていたわけではなかった。

## まとめ
- 総合的に見て、今読むなら LDDD がおすすめ。
  - エバンス本から 18年を経た業界の知見が取り込まれた最新のDDD
  - 概念が整理され、語り方、教え方も格段に進化している
  - 2020年代現在の技術状況での DDD の扱いという実用性
  - Building Blocks 偏重[^overemphasized]が無いためバランスが良く[^building_blocks3]、OOを前提とせずに読んでも違和感が少ない
- 手っ取り早く全要素を一望するには DDD Reference が良い。数回通読しても大して時間がかからない。パターンと基礎用語だけではなく、図もよく観察すると尚可。
- 記述を比較したり知識を補強したりする資料としてなら、IDDD[^IDDD2]、PPP of DDD、DDDD も良い。
- エバンス本は、20年前の業界の空気を知る（人によっては思いだす）意味では面白い。ニュートンの『プリンキピア』やユークリッドの『原論』のノリで読んでみると楽しいかもしれない。
- どの本を読むにしても、、、
  - Bounded Context/Ubiquitous Language、Context Mapping のパターン群、3つのサブドメインがまず大事
  - Building Blocks の中では Aggregate と Domain Event が群を抜いて重要。
[^building_blocks3]: 一見 Building Blocks 偏重に見える IDDD も、実は BoundedContext から Context Mapping の辺りにかけての記述も、簡潔ながらとても上手く解説している。

[^db]: XML Database や Object Database もあるにはあった。
[^oo]: COBOL、C、VB等から Java（これがそもそも OO なのかにはここでは触れない）界に来た人の啓蒙。今にして思えばかなり「上から」な使命感だが、当時は関数型言語もデータベースも、とりあえずOとかOOとかつけるとワンランク上がった感が醸しだせる空気があった。
[^uml1]: スリーアミーゴを始め、当時のオブジェクト指向の大家たちの多くがUML推しだった。ちなみに現代でoo界 ≒ アジャイル界と捉える誤解が散見されるが、当時のOO界の大家とアジャイル勢はほぼ別物で、根本的なところで鋭く対立してたりする（どっちつかずだった Cockburn や Fowler もある時点で決別した）。ここがあやふやなまま古いプラクティスをつまみ食いすると「混ぜるな危険」な状況が生じがち。
[^uml2]: OMG による標準化だったこともあり、OOPに先立って OOA、OOD で UMLを使うことこそ正統なオブジェクト指向とする見方も強かったと思う。『Agile Modeling(2002)』でも、「一般的なオブジェクト指向モデルの表記法かつ意味論である」としつつ、とはいえ UML も完全ではないから囚われる事のないようにと注意喚起されていた。
[^supple_design]: 型付 FP では特に Supple Design カテゴリとの親和性が高い。Side-Effect-Free Function はそのままFPの関数。Closure of Operation はモノイドまたは半群。Declarative Design は関数型パラダイムを含む上位の宣言型パラダイム。Drawing on Established Formalisms は圏論や抽象代数。また Assertion のある程度の部分が型レベルで表現できたり、Intention Revealing Interface も型クラスを利用できたりする。ただし Evans 自身は特に FP の素養があったわけでもないらしい。
[^core_domain]: Reference 本の DDD 三か条で「1. コアドメインに集中せよ」とされているほど重要で（この三か条は他の DDD本からもよく参照される）、これをスキップしてドメインにデザインを駆動させるのは無理。Lerning DDD では Core **Sub**domain と用語が調整されている。
[^ddd2003]: 2004 年の本として言及されることもあるが、発売日 2003/8/22 とあるので2003年とした。
[^context_map]: IDDD によれば 'Context is king' である。
[^bounded_context]: 「アーキテクチャ設計とは本質的に境界に関するものである（LDDDの Ruth Malan の引用）」。また、「ソフトウェアアーキテクチャとは境界線を引く技芸である（クリーンアーキテクチャ）」
[^bounded_context2]: 「境界を定めるための経験則の中でもサイズは一番使い物にならない（意訳）」と、PPPDの著者 Nick Tune の言葉が、LDDDで引用されている。
[^ubiquitous_language]: DDDD では「DDDとは Bounded Context内での Ubiquitous Language のモデリングである（意訳）」とまで言っている。PPPD でもまた 'most important of DDD' とされる。Reference 本 DDD 三箇条でも「3. Speak a ubiquitous language within an explicitly bounded context.」である。
[^supporting_subdomain]: PDDDでは supporting domain。昔は domain と subdomain が用語上あまり整理されていなかった。
[^partner_ship]: LDDD では、この Partnership と Shared Kernel が、Cooperation という Team Collabolation タイプに含まれる。
[^domain_service]: Application Service との混同を避けて、**Domain** Service と明示的に書く本が多い。
[^application_service]: （Domain）Service ではない方の Service
[^philosophy]: LDDD や 『A Philosophy of Software Design』で語られる deep とはまた別の概念。
[^building_blocks]: 別名 Tactical Patterns。ここに囚われすぎるとダメなのは、たいていの本で注意喚起されていてる（例えば PPPD では overemphasize という表現）。
[^big_ball_of_bud]: BBoM と略されることも多い。LDDD では BBoM > Bounded Context > Microservice > Distributed BBoM と大小関係を付けて粒度の問題について語っており、とてもリーズナブルである。
[^anemiec_and_functional]: behavior-rich を重視する OO と違い、FP では Anemic Domain Model はむしろ望ましいとの解説がある（PPPD や DDDD）。他の本でも data と behavior を分離する FP の利点がしばしば言及される。
[^layered_architecture]: LDDD では 3層と 4層を別物として扱い、永続化モデルが単一の場合の Transaction Script に 3層、Active Record に 4層を推奨している。
[^strategic_design]: この Context Mapping と Distillation と Large-scale Structure の3つで、Strategic Design のサブカテゴリ
[^evolving_order]: System Metaphor, Responsibility Layers, Knowledge Level, Pluggable Component Framework の4つを配下に持つ上位パターン 
[^system_metaphor]: eXtreme Programming からの借用。『Design It!』でも、「Make the Design Tangible」の10のパターンの一つに含まれていた。ちなみに『Pragmatic Thinking and Learning（Wetware本）』では、Metaphor は脳の創造的なモードと分析的なモードの待ち合わせ場所とされている。
[^microservices_patterns]: 2章からの引用'DDD and the microservice architecture are in almost perfect alignment.'。続く文で BoundedContext, Subdomain と Microservice の関係、またチーム面からの親和性について述べられる。
[^microservice]: マイクロサービスと BoundedContext の関係については、Adrian Cockcroft の "A microservice definition: loosely coupled service oriented architecture with bounded context" のとおり。上記のマイクロサービス本では特に LDDD で詳しく解説されている。
[^distillation]: DDD Quickly では、Context Mapping カテゴリの配下にパターンの一つのような形で並置されていた。
[^knowledge_level]: Fowler の『Analysis Pattern(1996)』で紹介されている分析技法で、ドメイン知識を操作レベルと知識レベルに分けるというもの。アナパタ全体で多用されている。
[^databases]: 例えば[この分類](https://www.ml4devs.com/images/illustrations/sql-vs-nosql-cheatsheet.webp)だと、RDB は12種のデータベースタイプのうちの一つという事になる。
[^other_books]: 各言語やフレームワークごとの DDD 本もあるが触れない（個人的には、正直あまり必要性も感じない）。
[^overemphasized]: Evans 自身が青い本を反省して、「BoundedContext や Strategic Design を差し置いてTactical Design について書きすぎた」と言っていたと何かの本に書いてあったが、見失った。見つけたら追記する。
[^waste_of_time]: DDDに限らず、長い時間かけて最初から最後のページまでめくって目を通した、あるいは読書会に毎回出た、なのに1ヶ月後には何も覚えてない、といった状況も技術書あるあるなので気をつけたい。
[^xml]: Eclipse でも、Java と UMLと XMLの三者間で相互に往来する EMF: Eclipse Modeling Framework が、とても格好良いイメージで期待されていた。
[^unified_process]: 昔風の階層型組織に則って、モデラー役の上級技術者がUMLダイアグラムを描いて、コーダー役の下級技術者が実装するような世界観。アラン・ケイよりスリーアミーゴやOMGが当時のOOの権威で、何ならそういうのがオブジェクト指向開発と考える向きも多かった。ちなみに ICONIX も軽量とはいえ、どちらかと言えばアジャイルよりはそっち寄り。
[^academic_fp]: もちろん00年代でも関数型プログラミングの仕事もあるにはあっただろうが、今のように「次の開発は Java 止めて純粋関数型言語でやろっか」みたいなノリは一切なかったとおもう。
[^shared_db]: サービスと DB の関係でも、Shared Database から Database per Service に価値観がシフトした。
[^integrity]: 日本語では別の訳語になるモデルのintegrity(整合性)とセキュリティのintegrity(完全性)が、『Security by Design』の観点では重なるという面白い知見。
[^functional_domain]: 型（の取りうる値の集合）から型への写像でドメインを捉える、表示的意味論ベースのパラダイムが DDD と親和性が高いように思う。
[^process_manager]: これも大古典である Hohpe Gregor の『Enterprise Integration Patterns』(略称EIP)でも解説されている重要な[パターン](https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html)。リアクティブ以降の現代 EDA の文脈でも、Saga の先のパターンとしてしばしば語られる。
[^IDDD2]: この本の当時は GitHub に置かれたサンプルプロジェクトがとても参考になったが、さすがに10年前の Java コードとなると陳腐してしまった感が否めない。
[^clean_architecture]: なぜか不思議と日本の業界では、DDD と クリーンアーキテクチャをワンセットで語りたがる人が多いが、DDD界隈からクリーンアーキテクチャへの言及も、逆にクリーンアーキテクチャ本から DDD への言及もそんなには無い。また Entity という語も DDDと別の意味で使われていたり、他の Port & Adapter 系と比べて特段DDDと相性が良いわけでもない。