软件脱胎于领域，软件由代码最终构成。这意味着，代码的目的在于反映出领域（这中间需要持续的设计、修改、简化直至清晰地反映出最初的愿景）。
在启动一个软件项目时，我们应该关注软件涉及的领域。
软件需要跟要它服务的领域和谐相处，否则，它会给领域引入麻烦，产生障碍、灾难甚至导致混乱等。
我们怎样才能让软件和领域和谐相处呢？最佳的方式是让软件成为领域的反射（映射）。
软件需要具现领域里重要的核心概念和元素，并精确实现它们之间的关系。软件需要对领域进行建模。
当我们跟领域专家交流时，我们会学到好多领域知识，但这些未加工的知识不能被容易地转换成软件构造，除非我们为它建立一个抽象——在脑海中建立一个蓝图。
开始时，这个蓝图总是不完整的，但随着时间的推移，经过不断的努力，我们会让它越来越好，让它看上去越来越清晰。
这个抽象是什么？它是一个模型，一个关于领域的模型。
按照Eric Evans的观点，领域模型不是一幅具体的图，它是那幅图要极力去传达的那个思想。
它也不是一个领域专家头脑中的知识，而是一个经过严格组织并进行选择性抽象的知识。
一幅图能够描绘和传达一个模型，同样，经过精心编写的代码和一段英语句子都能达到这个目的。
模型是软件设计中最基础的部分。我们需要它，是因为能够用它来处理复杂问题。我们对领域的所有的思考过程被汇总到这个模型中。
这样甚好，但它必须要超越我们的头脑，如果它止步不前，其实并不会有多大的作用。
我们需要就这个模型跟领域专家进行交流，跟资深的设计人员进行交流，跟开发人员进行交流。
模型是软件的根本，但我们需要找到一些方法来表现它，让它和其他事物交流。
在这个过程中我们并不是孤立的，所以我们需要彼此共享知识和信息，而且我们需要把它做得更好、更精确、更完整，没有二义性。
要做到这点有多种方式。常见的一种方式是将模型图形化：图、用例、画和图片等。
另一种方式是写，我们会写下我们对领域的愿景。
还有一种方式是使用语言，我们能够也应该针对要交流的领域内的特定问题建立一种语言。
简单来说，我们需要用模型来交流。
软件设计有不同的方法，其中之一是瀑布设计方法。这种方法包含了一些阶段。
业务专家提出一堆需求同业务分析人员进行交流，分析人员基于那些需求来创建模型并作为结果传递给开发人员，开发人员根据他们收到的内容开始编码。
在这个方法中，知识只有单一的流向。虽然这种方法作为软件设计的一个传统方法，这么多年来已经有了一定级别的成功应用，但它还是有它的缺点和局限。
主要问题是业务专家得不到分析人员的反馈信息，分析人员也得不到开发人员的反馈信息。
另一个方法是敏捷方法学，例如极限编程（XP）。这些方法学是不同于瀑布方法的一堆动作，产生背景是预先很难确定所有的需求，特别是需求经常变化的情况。
要想预先创建一个覆盖领域所有方面的完整模型确实很困难。
需要做出很多的思考，而且开始时常不能看到涉及到的所有的问题，也不能预见设计中某些带有负面影响或错误的部分。
敏捷方法试图解决的另一个问题被称为“分析瘫痪”，团队成员会因为害怕做出任何设计决定而无所事事。
尽管敏捷方法的倡导者承认设计决定的重要性，但他们反对预先设计。
相反，他们使用大量灵活的实现，通过由业务涉众持续参与的迭代开发和许多重构，开发团队更多地学习到了客户的领域知识，从而能够产出满足客户需要的软件。
敏捷方法也存在自己的问题和局限：他们提倡简单，但每个人都对“简单”的意义有着自己的观点。
同时，缺乏了真实可见的设计原则，由开发人员执行地持续重构会导致代码更难理解或者更难改变。
虽然瀑布方法可能会导致过度工程，但对过度工程的担心可能会带来另一种担心：害怕做出深度、彻底的设计。
本书描述了领域驱动设计的原则，应用这些原则会增进对领域内复杂问题进行建模和实现的开发过程能力。
领域驱动设计结合了设计和开发实践，展示了设计和开发如何协同工作以创建一个更好的解决方案。
优良的设计会加速开发的过程，而开发过程中的反馈也会进一步优化设计。
构建领域知识
通过提出正确的问题，正确地处理得到的信息，你和专家会开始勾勒领域的骨架视图，也就是领域模型。
这种骨架视图既不完整也不能保证是正确的，但它却是你需要的开始点，可以尽力判断出领域的基础性概念。
这是设计中很重要的一点。通常，软件架构师或开发人员都会和领域专家之间进行很长时间的讨论。
软件专家希望从领域专家那里获取知识，他们也不得不将它们转换成有用的形式。
从某种角度上讲，他们可能希望建立一种早期的原型以验证它是否能按照预期工作。
在这当中，他们可能会发现一些自己模型或者方法中的某些问题，可能想改变模型。交流不再是从领域专家到软件架构师再到更后面的开发人员的单向关系，它存在着反馈，这会帮助我们更好地建立模型，获得更清晰更准确的对模型的理解。领域专家掌握很多的专业技能，只是他们按照特殊的方式组织和使用这些知识，而这通常对要将它们实现到软件系统中不是件好事情。
通过与领域专家的交谈，软件设计人员的分析型思维会帮助他挖掘出一些领域中的关键概念，并且帮助构建出可用于将来讨论用的结构，我们将在下一章中看到这种结构。作为软件方面的专家（软件架构师和开发人员）和领域专家，我们会在一起创建领域的模型，这个模型会体现两个专业领域的交汇。这看上去是个很消耗时间的过程，并且确实如此，但是它也应该被这样做，因为软件的最终目的是去解决真实领域中的业务问题，所以它必须和领域完美结合。
