本文是从 What is Domain Driven Design?这篇文章翻译而来。
”…在很多领域，专家的作用体现在他们的专业知识上而不是智力上。“
-- Don Reinertsen
领域驱动设计(Domain Driven Design)是一种软件开发方法，目的是让软件系统在实现时准确的基于对真实业务过程的建模并根据真实业务过程的调整而调整。
传统的开发工作趋向于一种以技术为先导的过程，需求从业务方传递到开发团队，开发人员依据需求上的描述创造出最有可能的假想。
在瀑布开发过程中，这导致了大量的需要频繁校对，分析，复核和审批的需求文档。之后这些文档被交给开发团队去变成能够运行的软件。
敏捷开发方法同样可以采纳瀑布模式过程中产生的需求文档，但敏捷方法在实际的处理过程中会把它们分成很小的任务和“故事”，之后的开发工作将依据这些任务的排序。
领域驱动设计很大程度上使你从这两种截然不同的结果中抽身出来，让你能看到需求是如何在第一现场被收集到——如果你愿意看的话，它在动手先做的方式和在最后一分钟才做的方式之间做了弥补。
领域驱动设计方式知道需求是永远不会“完成”的，需求就像一个活的文档。更重要的是，这些仍待讨论的活文档实际上就是软件自身——所有的文档都是程序代码的一种影像，一种演示品。
随着软件系统的开发和发展，你对各种问题的理解也会更深——领域驱动设计就是要通过深入的理解问题来找到问题的解决方案。
然而，领域驱动设计真正的不同之处却是，它把软件系统当作业务过程的一个影射，是使能动，而不是驱动。领域驱动设计是要你深入到业务过程中，了解业务术语和实践方法。技术方面的事被放在了第二位，只是最终的一种手段而已。
Ubiquitous语言(UL)是领域驱动设计的中心——这是一种共有的不断成长的语言。它是一种来源于业务术语、经过开发团队的补充而产生的协商后的语言。如果一个业务人员不懂得UL里的一个术语，有可能是UL需要改进发展。如果一个技术人员不懂得UL里的一个术语，有可能是他们需要跟领域专家进行交流。
领域专家是领域驱动设计里第二重要的组成部分——这些人能够对这个领域有深入的了解，包括这个业务本身。这些人构成了开发过程中必要的组成部分。他们也许像一些敏捷开发方法里传统的产品拥有者那样不需要“全天候”的在职，但他们必须在开发过程中能被持续的接触到，而且随时准备好参与到开发过程中。领域专家不能被当作门外人，而应被当作领域驱动设计过程中的核心——他们非常像是开发团队中的一部分，就像普通的开发者和测试者一样。
领域驱动设计没有开始和结束——它是一个不断的再评估，再重构，再建模，再设计的持续过程——每一次的对话都会使你对问题有更进一步的理解。领域驱动设计没有“完成”点——它永远都在进行；Ubiquitous语言会不断发展和成长，领域模型随着对业务理解的改变而改变，代码不断的再组织和重构来更好的表现你的理解。
各种模拟产物产生又抛弃，而唯一真正有意义的只有代码。它是解决方案的唯一表达，是一种不再抽象的表达。文档是用来解释和描述系统的，而只有代码能不失分毫的做到这些。这就是说，在领域驱动设计里，代码必须保持高质量，要清晰，要有表达力，没有技术上省略和专门用语，尽可能的要让代码能够在被解释时对领域专家有些意义。
领域驱动设计里没有精巧的代码，也没有奇特的处理过程，或“你不需要知道”的模块。领域专家不需要成为开发人员来理解软件系统里用来做这些工作的关键部分是什么。他们同样也不需要考虑数据库或批处理任务或其他技术相关的方面。
领域驱动设计是敏捷方法的终极表达——它是用来处理不断变化和发展的需求的——正如任何一个从未涉足软件项目的人都知道——一个项目的需求从开始到结束保持一成不变是极其罕见的，绝大多数情况是它会随着业务的增长和变化而变化。
通过不断的交流，领域驱动设计会指导你用软件最精确的表达你的业务过程。