DDD,领域驱动设计（Domain Driven Design）,将改变你对世界的看法（正如面向对象分析与设计一样）。
DDD也是现代高并发模式如CQRS(Command Query Responsibility Segregation)等的敲门砖。
一般都认为它涉及的面很广(设计模式、架构模式、敏捷开发、面向对象等)，要实践起来是有些困难的。另一方面，它是Object-Oriented Programming done right。所以越早了解越早入门，对提高分析、设计、编程能力好处多多。尤其是项目经理、BA、架构师之类的人物，如果对DDD了解深入，将大大地提高项目或者软件的质量。
为啥呢？
DDD的立足点：一个软件系统的核心应该是业务领域建模(Domain Modeling)。像物理和数学世界一样，一个问题的分析和解决要依据一个“模型”。软件也应该是这样，因为软件是用来解决实际的领域的问题的。我们需要模型。这个模型从软件的需求而来。另一方面，因为需求也是逐步明确，逐步细化的，这个模型也将是演化的。“需求变化”，“演化”，是不是嗅到了敏捷开发的味道？是的，敏捷开发将是DDD的主线之一。
到这里，你可能会想：这么简单，我早就知道了。但其实，上面所说的模型还只是一个概念上的(Conceptual)模型，是传统的系统分析阶段得到的。长期以来领域模型没有很好地得到应用大概也是因为这个。因为属于分析产物的领域模型（也许体现为SFS，SSFS，也许只是脑海中的）与设计和实现脱节，并且将在实际的设计和开发中被遗忘。DDD要纠正这种错误做法：领域模型应该是设计和实现综合考虑的产物。做模型设计还要考虑实现？！我以前对世界的看法不是这样子的。。。
事实上，一个好的领域建模者(Domain Modeler)不仅会用白板分析，也会用代码来表达想法。一个 conceptual model 要想有用，就需要考虑 implementation issues. Think about it.一方面，分析设计系统模型不能关注太多技术细节，另一方面，DDD又要求我们关注实现，这不矛盾吗？这是DDD的难点之一。更关键的是，你在重构代码的时候也要重构你的模型！因为他们是对应的！这才是敏捷开发的感觉：你的设计随着你的代码的迭代也一起演变！
有两类人决定了软件的质量: Domain Experts 和 Developers.他们应该一起去建立领域模型。模型根本上是从领域专家而来。但是领域专家的模型可能有很多无用成分，需要开发者从计算或者软件科学的角度帮他们去伪存真去粗取精，甚至“优化工作流”。但是他们的语言不通。所以需要Ubiquitous Language 通用语言，领域专家也懂，开发者也懂。这种语言不像领域专家的语言那么啰嗦没有重点，又不像技术人员的语言那么用一堆技术词汇故弄玄虚。它简洁明了，直入主题，它主谓宾很明确，将具体的需求和用例抽象得有条有理。更进一步，你写的代码也是用这一套语言！这又是一大难关，怎么去创造这种语言呢？Practice。
以上是从软件工程角度蜻蜓点水般鸟瞰了一下DDD这个庞大的体系。下一次，我们将认识DDD的架构要素，就是大名鼎鼎的Aggregate（聚合）等概念。
有兴趣的读者可参考下面资料：
Eric Evans的书《Domain Driven Design》,这个适合深入研究用
InfoQ 的 Domain Driven Design Quickly，适合快速入门
《Practicing Domain Driven Design》，用C#.net的话一定要看
还有这几个blog：
