実はけっこう多い DDDの本

Last updated at 2023-11-26Posted at 2023-09-03

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

書籍・資料

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

初期のDDD本たち

DDD が出てきた00年代中盤はこんな感じだった。

DB といえばほぼ RDB一択³で、オンプレで SoR を開発していた。
オブジェクト指向を熱心に信奉し手続き型勢を啓蒙したいと考える人が多かった。⁴
UML 普及期⁵で、成果物にUMLの各種ダイアグラムを含める事が流行り始めた。⁶
XML 大全盛で、設定ファイルから Webサービスまで何でも XMLだった⁷。
WF への倦怠に伴い反復漸進型⁸開発への期待も高まってきたが、かと言ってすぐにアジャイルでもなく、メソドロジー論争からの流れで UP などの権威がまだ高かった⁹。¹⁰

エバンス本 (2003¹²): D3¹³

PoEAA で予告され¹⁴満を持して登場した大古典。以後の関連書籍や言説の量から客観的に見ても歴史的インパクトはとても大きいが、決して読みやすい本ではなく多くのDDD難民を生み出した。

DDD Quickly (2006): DQ¹⁵

エバンス本を要約した電子書籍でInfoQ でダウンロードできる。これで救われた DDD難民も当時は結構いたらしい¹⁶。『Secure By Design』では、まずこれを読むよう勧めている。

近現代のDDD本たち

エバンス本から10年後の2013年から現代までの本。この間、以下のようなことがあった。

NoSQLブーム以降、RDBが数ある選択肢のうちの一つになった¹⁷
クラウド技術やコンテナ技術が現れ、ほぼ大前提のレベルにまで普及した
世俗の開発でも関数型プログラミングが普及した¹⁸
リアクティブ、イベント駆動の概念・製品・技術が発達した
マイクロサービス、サーバーレスが普及した ¹⁹
アジャイルが普及し、ドメインエキスパートまで含めたチーム一丸で協働しながら、小さなステップで反復開発するスタイルが一般的になった

IDDD (2013): ID²⁰

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

DDD Reference (2015): RF²¹

Evans 自身が 12年分の知見を加味しつつ、青い本から DDD 要点を抜粋したカタログ。45のパターンが各 1ページ程度でまとめられ、非常に薄い²²。後発の DDD本からも参照されることが多い。

PPP of DDD (2015): PD²³

『Secure By Design』でも DDD理解の参考図書として推奨されている良書。現代DDDをよく説明している。LDDD からも参照あり。

DDD Distilled (2016): DD²⁴

IDDD の著者 Vaughn Vernon の別の DDD 本。IDDD よりかなり短いが、かといって抽象的すぎることもなく、図を多用して分かりやすく説明している。ちなみに 'distill' は DDD 用語としても頻出で、『Secure By Design』でも詳しく説明されている。

LDDD (2021): LD²⁵

BoundedContext や Subdomain 周りのパターンが原型をくずさない範囲で明確に整理された²⁶。これにより、どの状況でどのパターンを使うかの判断フローが明確になり、実用性が格段に高まった。2020年代に DDD を実践する場合に考慮すべきことが、ほぼ抜かりなく解説されている。

DDD周辺の本たち

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

Secure By Design (2019): SD²⁷

セキュリティの本だが、著者たち全員が最も影響をうけたものとしてDDDを挙げており、第3章の概説をはじめとして驚くほど DDD 関連の記述が多い。セキュリティの CIA-Tのなかでも I(Integrity) に特に関係が深い²⁸。

Domain Modeling Made Functional (2018): DF²⁹

実用上の選択肢がオブジェクト指向しかなかった時代と違い、関数型パラダイムでドメインを理解し³⁰モデル化することも身近になってきた。この本では第1章の 'Introducing Domain Driven Design' から始まり、以降の章でも DDD と FP の親和性の高さが随所で解説されている。

Microservice Patterns (2018): MP³¹

マイクロサービスのパターン本。サービス境界の問題や³²、イベント/メッセージングに関連して、DDD 関係の記述が多い。

Monolith to Microservices (2019): MM³³

マイクロサービスの大家である Sam Newman の本。DDD 関連のページ数は多くないが、マイクロサービスを開発するにあたって最低限知っておくべき DDD の核心を挙げているのが面白い。

パターン

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

Putting the Model to Work	D3	DQ	Rf	ID	PD	DD	LD	SD	DF	MP	MM
Bounded Context³⁴	○	◎	◎	◎	◎	◎	◎	◎	◎	○	◎
Ubiquitous Language³⁵	○	◎	◎	○	◎	◎	◎	○	◎	○
Continuous Integration	○	◎	◎	△	△	△				△
Model-Driven Design	○	◎	◎		◎
Hands-on Modelers	○		◎
Refactoring Toward Deeper Insight	◎	◎	◎	△	△	△			△	△
Building Blocks ³⁶	D3	DQ	Rf	ID	PD	DD	LD	SD	DF	MP	MM
Layered Architecture³⁷	○	◎	◎	○	○		◎		△	○
Entities	○	◎	◎	◎	◎	○	○	◎	○	○
Value Objects	○	◎	◎	◎	◎	○	○	○	○	○
Domain Events			◎	◎	◎	◎	○		◎	◎	○
Services³⁸	○	◎	◎	◎	◎		○			○
Modules	○	◎	◎	◎	○	△
Aggregates	○	◎	◎	◎	◎	◎	○	○	○	◎	◎
Repositories	○	◎	◎	◎	◎			△	△	○
Factories	○	◎	◎	◎	◎					○
Smart UI	○			○
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⁴⁰	D3	DQ	Rf	ID	PD	DD	LD	SD	DF	MP	MM
Context Map⁴¹	○	◎	◎	◎	◎	◎	○	◎	○
Partnership⁴²			◎	○	○	○	○
Shared Kernel	○	◎	◎	○	○	○	○		○
Customer/Supplier	○	◎	◎	○	○	○	◎		○
Conformist	○	◎	◎	○	○	○	○		○
Anticorruption Layer	○	◎	◎	○	○	○	○		◎
Open-host Service	○	◎	◎	○	○	○	○
Published Language	○		◎	○	○	○	○
Separate Ways	○	◎	◎	○	○	○	◎
Big Ball of Mud⁴³			◎	○	○	○			△
Distillation	D3	DQ	Rf	ID	PD	DD	LD	SD	DF	MP	MM
Core Domain⁴⁴	○	○	◎	○	◎	○	○		○	△
Generic Subdomains	○	○	◎	○	○	○	○		○	△
Supporting Subdomain⁴⁵	△		⁴⁶	○	○	○	○		○	△
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⁴⁷	○		◎	△
System Metaphor⁴⁸	○		◎
Responsibility Layers	○		◎		○
Knowledge Level⁴⁹	○		◎
Pluggable Component Framework	○		◎
DDD 外の参考概念	D3	DQ	Rf	ID	PD	DD	LD	SD	DF	MP	MM
Event Sourced Domain Model⁵⁰				○	○		◎			○
Domain Model (pattern)					○		◎			◎
Active Record				○			◎
Transaction Script				○			◎			◎
Anemic Domain Model⁵¹				○	○				○
Event Storming					○	○			◎	○	◎
Event Sourcing				◎	◎	○	◎		◎	◎	△
CQRS				◎	◎	○	◎		◎	◎
Saga				○			○		○	◎	◎
Process Manager⁵²							○		○
Microservice⁵³					△		◎	◎	△	◎	◎
Port & Adapter			○	○	○	○	○		○	○
Application Service⁵⁴				◎	◎					△
Strangler Fig							○			○	◎

パターン・カテゴリごとの寸評

Putting the Model to Work

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

Building Blocks

特に重要なのは Aggregateで、『Monolith to Microservices』では最低限知っておくべき DDDの事として、Bounded Context と共に挙げられる。関数型の場合には若干扱いが異なるが、DMMF や PPPD ではその点についても解説される。
次に重要なのが Domain Event で、モダンなDDD本はもちろん、DMMF やマイクロサービス本でも手厚く解説される。この Domain Event の有無が、古い DDDとモダンな DDDの最も顕著な違いでもある⁵⁷。

Supple Design

PPP of DDD くらいまでは若干記述があったが、最近の本ではあまり触れられない。このカテゴリは実はFPに関係が深く³⁹、単発のネット記事などではたまに触れられるが、今回調べた DMMF では特に触れられていない⁵⁸。

Context Mapping

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

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）を含めた４つの選択肢として再整理された。これに伴い、長らくアンチパターン扱い⁶⁰だった TS が設計判断の決定木の中で復権し、一方 DM も「サブドメインタイプ＝Core」かつ「変更履歴が不要なケース」の条件下のただの選択肢になった。
Event Storming から Process Managerあたり: Domain Event が DDD に含まれたことに伴い、イベント関連の概念についての言及も増えた。EDAの実装技法にとどまらず、Event Storming に見られるようにドメイン理解やコミュニケーションの面でも影響が大きい。
Microservice その他のパターン群: サービス粒度の問題に BoudedContext/Aggregate が強く関連することから、Microservice 関連のパターンがよく言及される。アーキテクチャの層に関連する Onion, Hexagonal, Clean⁶¹ は Port & Adapter として一括した。

まとめ

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

DDDに限らず、長い時間かけて最初から最後のページまでめくって目を通した、あるいは読書会に毎回出た、なのに1ヶ月後には何も覚えてない、といった状況も技術書あるあるなので気をつけたい。 ↩
各言語やフレームワークごとの DDD 本もあるが触れない（個人的には、正直あまり必要性も感じない）。 ↩
XML Database や Object Database もあるにはあった。 ↩
COBOL、C、VB等から Java（これがそもそも OO なのかにはここでは触れない）界に来た人の啓蒙。今にして思えばかなり「上から」な使命感だが、当時は関数型言語もデータベースも、とりあえずOとかOOとかつけるとワンランク上がった感が醸しだせる空気があった。 ↩
OMG による標準化だったこともあり、OOPに先立って OOA、OOD で UMLを使うことこそ正統なオブジェクト指向とする見方も強かったと思う。『Agile Modeling(2002)』でも、「一般的なオブジェクト指向モデルの表記法かつ意味論である」としつつ、とはいえ UML も完全ではないから囚われる事のないようにと注意喚起されていた。 ↩
スリーアミーゴを始め、当時のオブジェクト指向の大家たちの多くがUML推しだった。ちなみに現代でoo界 ≒ アジャイル界と捉える誤解が散見されるが、当時のOO界の大家とアジャイル勢はほぼ別物で、根本的なところで鋭く対立してたりする（どっちつかずだった Cockburn や Fowler もある時点で決別した）。ここがあやふやなまま古いプラクティスをつまみ食いすると「混ぜるな危険」な状況が生じがち。 ↩
Eclipse でも、Java と UMLと XMLの三者間で相互に往来する EMF: Eclipse Modeling Framework が、とても格好良いイメージで期待されていた。 ↩
I&I (Iterative and Incrimental) process。Alistair Cockburn によれば Incremental = "add onto", Iterative = "alter" である。 ↩
昔風の階層型組織に則って、モデラー役の上級技術者がUMLダイアグラムを描いて、コーダー役の下級技術者が実装するような世界観。アラン・ケイよりスリーアミーゴやOMGが当時のOOの権威で、何ならそういうのがオブジェクト指向開発と考える向きも多かった。ちなみに ICONIX も軽量とはいえ、どちらかと言えばアジャイルよりはそっち寄り。 ↩
ちなみにアジャイルといっても、当時はスクラムじゃなくXP¹¹が本命だった。 ↩
個人的には、今でもどちらかというとスクラムより XP が好ましい。 ↩
2004 年の本として言及されることもあるが、発売日 2003/8/22 とあるので2003年とした。 ↩
俗に言うエバンス本、または青い本。正式には『Domain-Driven Design: Tackling Complexity in the Heart of Software』。 ↩
Domain Model パターンの解説で、執筆中であると言及されていた。 ↩
正式には『Domain Driven Design Quickly』 (Abel Avram & Floyd Marinescu, 2006) ↩
国内だと、オージス総研/オブジェクトの広場の「DDD難民に捧げるDomain-Driven Designのエッセンス」もよく読まれた ↩
例えばこの分類だと、RDB は12種のデータベースタイプのうちの一つという事になる。 ↩
もちろん00年代でも関数型プログラミングの仕事もあるにはあっただろうが、今のように「次の開発は Java 止めて純粋関数型言語でやろっか」みたいなノリは一切なかったとおもう。 ↩
サービスと DB の関係でも、Shared Database から Database per Service に価値観がシフトした。 ↩
正式には『Implementing Domain-Driven Design』 (Vaughn Vernon, 2013) ↩
正式には『Domain-Driven Design Reference』 (Evans Eric, 2015) ↩
極限まで短くなっている分抽象度が高いので、必ずしも簡単とは言えないが、個人的には青い本を1回読むより、これを10回読むほうが短時間で多くの知見が得られると思う。 ↩
正式には『Patterns, Principles, and Practices of Domain-Driven Design』 (Scott Millett & Nick Tune, 2015) ↩
正式には『Domain-Driven Design Distilled』 (Vaughn Vernon, 2016) ↩
正式には『Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy』 (Vlad Khononov, 2021) ↩
Core Domain が Core Subdomainになったり、Bounded Context を関連付けるパターン群が階層化されたり。 ↩
『Secure By Design』 (Daniel Sawano, Dan Bergh Johnssonなど 2019) ↩
日本語では別の訳語になるモデルのintegrity(整合性)とセキュリティのintegrity(完全性)が、『Security by Design』の観点では重なるという面白い知見。 ↩
正式には『Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#』 (Scott Wlaschin, 2018) ↩
型（の取りうる値の集合）から型への写像でドメインを捉える、表示的意味論ベースのパラダイムが DDD と親和性が高いように思う。 ↩
正式には『Microservices Patterns: With examples in Java』 (Chris Richardson, 2018) ↩
2章からの引用'DDD and the microservice architecture are in almost perfect alignment.'。続く文で BoundedContext, Subdomain と Microservice の関係、またチーム面からの親和性について述べられる。 ↩
正式には『Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith』 (Sam Newman, 2019) ↩
「アーキテクチャ設計とは本質的に境界に関するものである（LDDDの Ruth Malan の引用）」。また、「ソフトウェアアーキテクチャとは境界線を引く技芸である（クリーンアーキテクチャ）」 ↩
DDDD では「DDDとは Bounded Context内での Ubiquitous Language のモデリングである（意訳）」とまで言っている。PPPD でもまた 'most important of DDD' とされる。Reference 本 DDD 三箇条でも「3. Speak a ubiquitous language within an explicitly bounded context.」である。 ↩
別名 Tactical Patterns。ここに囚われすぎるとダメなのは、たいていの本で注意喚起されていてる（例えば PPPD では overemphasize という表現）。 ↩
LDDD では 3層と 4層を別物として扱い、永続化モデルが単一の場合の Transaction Script に 3層、Active Record に 4層を推奨している。 ↩
Application Service との混同を避けて、Domain Service と明示的に書く本が多い。 ↩
型付 FP では特に Supple Design カテゴリとの親和性が高い。Side-Effect-Free Function はそのままFPの関数。Closure of Operation はモノイドまたは半群。Declarative Design は関数型パラダイムを含む上位の宣言型パラダイム。Drawing on Established Formalisms は圏論や抽象代数。また Assertion のある程度の部分が型レベルで表現できたり、Intention Revealing Interface も型クラスを利用できたりする。ただし Evans 自身は特に FP の素養があったわけでもないらしい。 ↩ ↩²
この Context Mapping と Distillation と Large-scale Structure の3つで、Strategic Design のサブカテゴリ ↩
IDDD によれば 'Context is king' である。 ↩
LDDD では、この Partnership と Shared Kernel が、Cooperation という Team Collabolation タイプに含まれる。 ↩
BBoM と略されることも多い。LDDD では BBoM > Bounded Context > Microservice > Distributed BBoM と大小関係を付けて粒度の問題について語っており、とてもリーズナブルである。 ↩
Reference 本の DDD 三か条で「1. コアドメインに集中せよ」とされているほど重要で（この三か条は他の DDD本からもよく参照される）、これをスキップしてドメインにデザインを駆動させるのは無理。Lerning DDD では Core Subdomain と用語が調整されている。 ↩
PDDDでは supporting domain。昔は domain と subdomain が用語上あまり整理されていなかった。 ↩
DDD Reference にないが、Subdomain の分類は Core, Generic, Supporting の３つ（あるいは Generic & Supporting を含めて４つ）とするのが今では一般的なのでこの位置に書いた ↩
System Metaphor, Responsibility Layers, Knowledge Level, Pluggable Component Framework の4つを配下に持つ上位パターン ↩
eXtreme Programming からの借用。『Design It!』でも、「Make the Design Tangible」の10のパターンの一つに含まれていた。ちなみに『Pragmatic Thinking and Learning（Wetware本）』では、Metaphor は脳の創造的なモードと分析的なモードの待ち合わせ場所とされている。 ↩
Fowler の『Analysis Pattern(1996)』で紹介されている分析技法で、ドメイン知識を操作レベルと知識レベルに分けるというもの。アナパタ全体で多用されている。 ↩
ここでは Learning DDD の用語の Event Sourced Domain Model とした。Implementing DDD では A+ES、Microservice Patterns では event-sourcing based aggregate と言っている。 ↩
behavior-rich を重視する OO と違い、FP では Anemic Domain Model はむしろ望ましいとの解説がある（PPPD や DDDD）。他の本でも data と behavior を分離する FP の利点がしばしば言及される。 ↩
これも大古典である Hohpe Gregor の『Enterprise Integration Patterns』(略称EIP)でも解説されている重要なパターン。リアクティブ以降の現代 EDA の文脈でも、Saga の先のパターンとしてしばしば語られる。 ↩
マイクロサービスと BoundedContext の関係については、Adrian Cockcroft の "A microservice definition: loosely coupled service oriented architecture with bounded context" のとおり。上記のマイクロサービス本では特に LDDD で詳しく解説されている。 ↩
（Domain）Service ではない方の Service ↩
Ubiquitous Language の開発こそ DDD と言われることもあるが、これとて Bounded Context 無しには成立しない。 ↩
LDDD や『A Philosophy of Software Design』で語られる deep とはまた別の概念。 ↩
『From Object to Function』という関数型ドメインモデリングの本でも、DDD について言及しているのは、イベントに着目したドメインモデリングを二章に渡って解説してる部分だった。そこでも Aggregate と Domain Event にコマンドを加えた道具立てで、「状態」の変化について語っている。 ↩
Supple Design のパターン群と特に親和性があるのは表示的意味論ベースのFPである一方、DMMF では微妙にテイストが違うという差かもしれない。 ↩
DDD Quickly では、Context Mapping カテゴリの配下にパターンの一つのような形で並置されていた。 ↩
もともと PoEAA では、メリデメや使える場面なども含めて記述されたパターンの一つであり、無条件にアンチパターンとされていたわけではなかった。 ↩
なぜか不思議と日本の業界では、DDD とクリーンアーキテクチャをワンセットで語りたがる人が多いが、DDD界隈からクリーンアーキテクチャへの言及も、逆にクリーンアーキテクチャ本から DDD への言及もそんなには無い。また Entity という語も DDDと別の意味で使われていたり、他の Port & Adapter 系と比べて特段DDDと相性が良いわけでもない。 ↩
Evans 自身が青い本を反省して、「BoundedContext や Strategic Design を差し置いてTactical Design について書きすぎた」と言っていたと何かの本に書いてあったが、見失った。見つけたら追記する。 ↩
一見 Building Blocks 偏重に見える IDDD も、実は BoundedContext から Context Mapping の辺りにかけての記述も、簡潔ながらとても上手く解説している。 ↩
この本の当時は GitHub に置かれたサンプルプロジェクトがとても参考になったが、さすがに10年前の Java コードとなると陳腐してしまった感が否めない。 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

実はけっこう多い DDDの本

書籍・資料

初期のDDD本たち

エバンス本 (200312): D313

DDD Quickly (2006): DQ15

近現代のDDD本たち

IDDD (2013): ID20

DDD Reference (2015): RF21

PPP of DDD (2015): PD23

DDD Distilled (2016): DD24

LDDD (2021): LD25