「実践ドメイン駆動設計」本の用語をまとめていきます。

#DDD

ドメイン駆動設計、略してDDDと呼ばれるソフトウェア開発手法がある。より高品質のソフトウェアモデルを設計する手助けとなる手法だ。これをうまく使いこなせば、設計した結果が、そのソフトウェアの動作を明確に表すようにできる。...
p.1

DDDでは、ドメインエキスパートとソフトウェア開発者が力を合わせて、業務のエキスパートのメンタルモデルを反映したソフトウェアを開発する。これは決して、「現実世界」をそのままモデリングするということではない。DDDでは、現状をそのままモデリングするのではなく、業務により役立つモデルを作る。時には、使いやすいモデルと現状を反映したモデルとが食い違うかもしれない。しかし、そんな場合には使いやすいモデルを選択するのがDDDだ。
p.9

#ユビキタス言語

要するにユビキタス言語って･･････
業務で使う用語のことでしょ？
違うね。
ああ、業界で標準として定められている用語のことか。
それもちょっと違う
ドメインエキスパートがふだん使っている言葉のこと？
残念ながら、それも違う。
ユビキタス言語とは、ドメインエキスパートやソフトウェア開発者を含めたチーム全体で作り上げる共有言語のこと。
これが正解。わかったかな？
p.20

#境界づけられたコンテキスト

忘れてはいけない。境界づけられたコンテキストは明示的な境界であり、ドメインモデルがどこに属するのかを表すものである。ドメインモデルは、ユビキタス言語をソフトウェアモデルとして表したものだ。境界を設ける理由は、各モデルの内部的な概念やプロパティ・操作がそれぞれ特別な意味を持つからだ。...
p.58

境界づけられたコンテキストは明示的な境界であり、ドメインモデルがどこに属するのかを表すものである。境界の内部では、ユビキタス言語のあらゆる言語やフレーズが、特別な意味を持つ。そして、境界内のモデルは、その言語を正確に反映したものとなる。
p.58

境界づけられたコンテキストの主目的は、ユビキタス言語やそのドメインモデルをカプセル化することだ。...
p.64

境界づけられたコンテキストごとに、それぞれのユビキタス言語が存在する。
p.23

#ドメインモデル

忘れてはいけない。境界づけられたコンテキストは明示的な境界であり、ドメインモデルがどこに属するのかを表すものである。ドメインモデルは、ユビキタス言語をソフトウェアモデルとして表したものだ。境界を設ける理由は、各モデルの内部的な概念やプロパティ・操作がそれぞれ特別な意味を持つからだ。...
p.58

#その他

DDDでの設計方針は、いわばソフトウェアモデルをテストファーストで素早く洗練させていくようなものだ。...
p.35

各サブドメインを、境界づけられたコンテキストと一対一で対応させるのが、望ましいゴールである。...
p.54

DDDを実践する際には、個々の境界づけられたコンテキストについて、そのドメインモデルで使われる用語の意味を確実に理解しようと心がける。ソフトウェアをうまくモデリングするには、少なくともそうでなければいけない。特に、言語の境界を気にする。これらの概念的な境界が、DDDを実践する上での鍵となる。
p.45

... DDDを使うときには、境界づけられたコンテキストの内部でモデルを開発する。ドメインモデルを開発するということは、事業ドメイン全体の中で特定の部分にだけ注目するためのひとつの方法なのだ。...
p.42

#軽量DDD

軽量DDDとは、DDDの戦術的パターンの一部だけをつまみ食いする方法で、ユビキタス言語を見つけ出し育てていこうなどという気は毛頭ない。おまけにこの手法は、境界づけられたコンテキストやコンテキストマッピングを使わずに済ませることが多い。技術面だけに注目して、技術的な問題だけを解決したがっているのだ。この方法にはメリットもあるが、戦略的モデリングを併用したときのような大きな見返りは得られない。
p.38