领域驱动设计

软件开发过程的重点：它必须以业务领域为中心。让模型植根于领域、并精确反映出领域中的基础概念是建立模型的一个最重要的基础。通用语言应该在建模过程中广泛尝试以推动软件专家和领域专家之间的沟通，以及发现要在模型中使用的主要的领域概念。建模过程的目的是创建一个优良的模型，下一步将模型实现成代码。这是软件开发过程中同等重要的两个阶段。创建了优良的模型，但却未能将其成功地转换成代码把软件的质量带入未知境地。

曾经发生过软件分析人员和业务领域专家在一起工作了若干个月，一起发现了领域的基础元素，强调了元素之间的关系，创建了一个正确的模型，模型也正确捕获了领域知识。然后模型被传递给了软件开发人员。开发人员看模型时可能会发现模型中的有些概念或者关系不能被正确地转换成代码。所以他们使用模型作为灵感的源泉，创建了自己的设计，虽然某些设计借鉴了模型的思想，另外他们还增加了很多自己的东西。开发过程继续进行，更多的类被加入到代码中，进一步加大了原始模型和最终实现的差距。在这种情况下，很难保证产生优良的最终结果。优秀的开发人员可能会让一个产品最终交付使用，但它能经得起生产环境的考验吗？它能容易地被扩展吗？它能容易地被维护吗？

任何领域都能被表现成多种模型，每一种模型都能用不同的方式表现成代码。对每一个特殊问题而言，可能会对应不止一个解决方案。选择一个能够被轻易和准确转换成代码的模型很重要。最根本的问题是：我们应该如何动手处理从模型到代码的转换。

一个推荐的设计技巧是使用分析模型，它被认为是从代码设计中分离出来、通常是由多个人完成的。分析模型是业务领域分析的结果，其产生的模型不考虑软件需要如何实现。这样的一个模型可用来理解领域，它建立了特定级别的知识，模型看上去会很正确。软件不是这个阶段要考虑的，因为它的介入会被看作是一个导致混乱的因素。这个模型到达开发人员那里后，由他们来做设计的工作。因为这个模型没有涉及到设计原则，它可能不能很好地完成目标。因此开发人员不得不修改它，或者建立分离的设计。在模型和代码之间也不再存在映射关系。最终的结果是分析模型在编码开始后就被放弃了。