本書は、ドメイン駆動設計（DDD:Domain Driven Design）について書かれているで、ドメインモデル、エンタープライズアプリケーションアーキテクチャ、アーキテクチャパターン、テスト駆動開発を勉強する本です。
この本のお勧めの点の一つが、筆者の経験をもとにした生きたサンプルにあります。「システム開発は○○の理由でドメイン駆動設計を行ったほうがよい。こういう背景があって、こういうアーキテクチャパターンの適用を考えていく。」こういった生きた経験が本書にちりばめられています。
対象読者は業務アプリケーション開発に携わるアーキテクチャ、システムエンジニア、開発者さん達です。最近は定着したドメイン駆動設計（ドメイン駆動開発）という言葉ですが、現場で実際に使われているのは実は少ないのではないでしょうか。ドメイン駆動で設計するとはどういったことなのか？本書を読めば、新しい視点が学べると思います。お薦めの一冊です。
ドメイン駆動設計とは
この本の最大のテーマは、ドメインモデルをクリーンに作りつつ、永続記憶とも仲良くする方法である。ドメインモデルのようなもののための永続記憶はどのように構成されるかを示し、ドメインモデルとデータベースの間に橋をかける。
ユースケースとトランザクションスクリプト
ユースケースとはシステムの一つの機能（振る舞い）をユーザの視点から記述するものです。著者の Jimmy Nilsson は、かつてはユースケース一つにつき一つのクラスを作って機能を設計していたそうです。おそらく、いわゆる「3階層アーキテクチャのビジネスロジック層におけるサービスクラス」のことだと思われます。
この方法で設計を行うと、機能を呼び出して結果を得るのに一つのサービスクラスの一つのメソッドを呼び出すだけという構造になります。これが手続き型のトランザクションスクリプトというアーキテクチャパターンです。ユースケースを一つにつきサービスクラスを一つ作ると、一つの機能がそのクラスにカプセル化され処理の見通しはよくなります。
ドメイン駆動設計（Domain Driven Design）を重視する理由
ユースケースは確かに顧客との話し合いにはとても有効なものです。しかし、システムを設計するのにユースケースにとらわれる必要はないというのが筆者らの主張のようです。ユースケースでシステムの外観（インターフェース）を設計し、モデルによってドメインの主要コンセプト、業務のコアを定義し設計していくというのが効率的なシステム開発につながるのではないかと考えています。
最近の技術の発達のおかげで、顧客とモデルをベースに議論を行うことも不可能ではなくなってきました。
オブジェクト指向とドメインモデル
モデルを重視してシステムを設計すればおのずとオブジェクト指向でシステムを開発することになります。これをすんなり実装に落とすとなれば、当然ドメインモデルパターンのアーキテクチャを適用するのが自然の流れです。
ドメインをモデリングし、それをすんなり実装に落とすためにビジネスロジックにドメインモデルパターンを適用するのがドメイン駆動設計のコアの考え方です。
ドメインモデルとデータベース
データベースの設計方針
ドメインモデルで設計を進めていくと、当然データベースの設計をドメインモデル寄りにする必要が出てきます。しかしここで問題がでてくることになります。
データベースは今でもリレーショナルデータベースが一般的に使われています。リレーショナルデータベースは集合を基礎としたものになっています。ドメインモデルも集合を基礎としているのは変わりません。しかしドメインモデル（オブジェクト指向）はオブジェクトのデータ構造を出来るだけカプセル化し、振る舞いをオブジェクトに持たせようとするためデータベースのモデルと集合の粒度が異なるのです。
設計ということでは、粒度が大きく異なる。例を使ってこの点を明らかにしよう。特定の人物について、家庭用電話番号ひとつと仕事用電話番号ひとつを管理したいとする。（中略）
ここで重要なのは、1:1でもすべてのカラムが通常一つのテーブルで定義されていることである。オブジェクト指向モデルでは、Person と PhoneNumber の2つのクラスを作るのが普通だろう。そして Person のインスタンスは 2つの PhoneNumber インスタンスを組み合わせたものになる。リレーショナルモデルでも同じようなことができなわけではないが、通常は無意味である。リレーショナルモデルでは、テーブルの定義に動作を結び付けたりはしないので、定義を再利用しようなどとは考えない。これはオブジェクト指向モデルの逆である。
もう一つあるのは、データベースは継承をサポートしないことです。つまり、ポリモーフィズムが実現できないのです。オブジェクト指向では継承（ポリモーフィズム）は重要な概念です。
データマッパー（O/Rマッパー）
上で述べたようなデータベースモデルとオブジェクト指向モデルの乖離（かいり）のことをインピーダンスミスマッチと呼びます。そして、このインピーダンスミスマッチを埋める目的で導入されるものに、データマッパー（O/Rマッパー）があります。Java では Hibernate が有名です。
本書に書いてあること
- ドメイン駆動設計
- ドメインモデルが重要な理由
- アーキテクチャパターンとしてのドメインモデルの有効性
- テスト駆動開発によるモデルの見つけ方
- ドメインモデルに対するルール
- 永続化方針
- PoEAA の応用としてのインフラパターン
- NHibernate（.Net ようのO/Rマッパー）の導入
- 設計テクニック：SOA、DI、AOP
- UIに関する設計
- ドメインモデルパターン再考
ドメインモデルを現場にどうやって適用するか、なぜドメインモデルなのか、ドメインモデルを使った実際の設計例などが知りたい人は、ぜひ本書を読んでください。440ページ近くありますが、すんなり読めてしまうくらいどっぷりはまれます。