エリック・エヴァンスさんが提唱しています。
QCon Tokyo 2011 アーキテクチャパネルディスカッション＋DDD雑多ネタ
上記記事を見て、僕も思うところを書いていきます。DDD系の話は、議論になったりすることもありますが、１エンジニアのつぶやきと思ってみてください。（文中の引用文は、上記記事から引用させていただいています。）
基本概念
作成するシステムのプログラムコードと、ドメイン（現実の業務）が一致することによって、
主にコアドメインへの注力によって競争上の優位、市場優位につなげる
という。
ドメイン駆動設計を実践するための方法
レイヤードアーキテクチャ
ドメインロジックと、それ以外（DBやViewなど）を切り離すのが目的
最近のシステム設計もレイヤードアーキテクチャを採用していたりするので、DDDじゃなくても採用したほうが良いと思っています。
ドメインはオブジェクト指向言語が表しやすい？
ドメインロジックは、オブジェクト指向言語が一番表しやすいらしい。
個人的には、関数型言語でもエッセンスだけ取り入れるとかは、出来ると思う。
ユビキタス言語
全員で業務の言葉だけを統一して使い、技術用語や社内用語など統一されていない用語は使わない。
チーム内でドメインの言葉を使うように統一することにより、人によって同じ意味のものを違う単語で話しているとかなくなる。
そして、ドメインの言葉をコードにそのまま落とし込むことで、ビジネスパーソンの理解率向上が見込める。
（英語圏の人はドメインの言葉とコードが共に英語なので完全に一致する。日本人どうしようか？問題はある。）
ドメイン駆動設計で車について語ると？
一般的な車の仕様
- 燃料計やガソリンタンクを見ると、車のガソリン量を知ることが出来る。
- タイヤを見ても、車のガソリン量を知ることは出来ない。
システムに落としこんだ場合
- 燃料計クラスとか、ガソリンタンククラスのみが、ガソリン量を取得出来る
- タイヤクラスは、ガソリン量を知ることは出来ない。
ドメインと実装を合わせるのであれば、ガソリン量を知っていて良いのは、燃料計クラスとガソリンのタンククラスぐらいだと思います。
なので、下記はやりがちではありますが、駄目なパターンです。
タイヤクラスからでも、DBにガソリン量を取得に行けるので、取れます(^q^)
ちゃんと作っていくと、ドメインを知っている人は、かなりスッとコードベースの理解が進むと思います。
また実際に、現実のドメインと、ソースコードが一致していた場合、現実で難しい変更は、ソースコードでも難しい変更となるはず（逆も然り）。ビジネスパーソンに理解を得られる工数を言えるようになるかも？です。
ユビキタス言語と日本語の壁
エヴァンス氏の回答
「ドメインエキスパートがこの言葉（日本語コメントで書かれたクラス名）を使っているのなら、なぜクラス名にこれを使わない？」とのこと。「日本語でJava等を書くと、Java慣習にかたっぱしから違反してしまうので問題なんだ、コードも読みづらいし」と反論（？）してみたものの、「重要なのはドメインの概念であって、技術的な問題はそれに比べれば瑣末なものだろう？」と言われてしまい、もう納得するしかなかった。
徹底しているなぁと。でもやっぱり日本人は厳しそう。クラス名とかメソッド名は英語で、docコメントでユビキタス言語と合わせるというのが出来る限界なのでは無いかなぁ？と思います。
まとめ
DDDやりすぎると、
- コードが複雑化してしまった
- 普通に実装するよりも工数が掛かる
とかあるみたいです。
でも、DDDのドメインとコードの一致というものは、わかりやすいコードになるはずです。
結構、対極的な位置にある「Rich Hickeyさんの記事」の話も踏まえつつ、うまいことシステムを設計できたらいいなぁと思います。