> ソフトウェアは、業務側が「こうしたい」と考えていたことを、ソフトウェア開発者が翻訳したようなものになってしまうことが多い。できあがったソフトウェアがドメインエキスパートのメンタルモデルをきちんと反映できているわけではなく、仮にできていたとしても部分的なものに過ぎない。時がたつにつれて、この断絶のコストは高くつくようになる。開発にかかわったメンバーが他のプロジェクトに移ったり転職したりした時点で、ドメインに関する知識のソフトウェアへの翻訳は消え去ってしまう。（事業価値をもたらすのは難しい）
> ここで言う「チーム」とは、ドメインエキスパートとソフトウェア開発者がどちらも参加しているものだ。「私たちとあの人たち」ではない。常に「私たち」だけになる。（DDD がどのように役立つか）
良書。
決して読みやすい本ではないが、それは説明の悪さにあるのではなくて、DDD を現実のサービスに適用する際の難しさ（自由度の高さ）にあるのではないかと感じる。
概念的すぎず、ドメイン、バリューオブジェクト、エンティティなど DDD の基本的な概念が定義から記述されている。慣例はそれとして、「本来それらの概念はどのようなものであるべきか」を DDD の立場から考えるための視点を与えてくれる。
> ソフトウェア開発の世界では、...豊かな振る舞いを備えたドメインの概念を設計するのではなく、まずはデータの属性（カラム）と関連（外部キー）を考えてしまう。（エンティティ）
> Java の世界では、インターフェイス名の後ろに Impl を続けたものを、実装クラスの名前とするのが一般的だ。...実装クラスをこんな名前にできるということは、そもそもセパレートインターフェイスなど必要なかったという証ではないだろうか。（セパレートインターフェイスは必須なのか）
