为什么领域建模？

来自于响应式设计者The Responsible Designer的一篇博文：为什么领域建模？Why Domain Modeling?

文章大意如下：

(我们知道一个软件的产生经过如下大概过程：
1.需求分析 2.软件设计 3.程序开发 4.测试 5。交付)

面向对象分析和面向对象设计两个阶段(其中1和2)之间一直存在距离（如书籍Object Oriented Analysis (2nd Edition) (Yourdon Press Computing Series) [Hardcover]）：

需求分析时，你产生了一系列的任务描述和模型的对象，其中包括领域概念的陈述，并表明如何将这些对象交互来完成一些工作。 但你不能直接实现这些对象。

在面向对象的设计阶段中，你要完善之前分析模型，考虑到实施和技术的限制。 只有这样，设计完成后，才能落实到代码编程写程序。

也就是说，在分析或设计过程中产生的任何模型都需要大量的完善，才能根据其写程序。

我们很多人模糊了分析和设计编程之间界限。 在实践中，我们的工作往往是完全不同的迭代周期推动的。 我们可以分析问题，迅速勾勒出一些设计理念，然后实施。 我们可能会使用CRC卡，我们的对象模型可能会被我们将丢弃。

有时，分析问题和围绕问题设计实施的解决方案之间的差距并不显着。 有时，不同的人做了分析，而其他人进行设计和编程，但，开发人员能够多次做所有这些活动。

我们很少看到有人出具详细的对象的分析和设计模型。 良好的对象设计被程序认为是太困难，并没有时间。直接进入编码，结果丧失了良好的设计。

不管队伍是否实现敏捷开发，缺乏模型是很常见的，最常见的做法是有很详细的ER模型， 他们不漏掉任何细节，很难找到重点(没有显隐 没有主次)。

如果你的软件是复杂的，需求又瞬息万变，战略上你又没有做任何的领域建模，你可能会错过真正重要的东西。 如果您的软件是复杂的话，你可以大大受益于域建模。

如果你挖掘出域模型，您能形成在需求问题域与您的代码之间深刻的一致的共同理解。 你的任务不是仅仅提供软件可以运行的功能，而是嵌入到这些运行功能中的有关业务领域的解决方案知识。

代码中将使用对象表达业务领域的概念。 你会挑剔类和方法名称，使他们准确地反映了业务领域的概念。 您将有可以持续进行讨论的领域专家，共同探讨和完善对业务领域的理解。

一路上，你可以勾画和修改的域模型。 你会努力地维护以及加强明确业务概念和代码之间的连接。 当你重构你的设计，你能获得更深入的了解，你不会忘记那些反映业务领域的代码。

如果开发人员和领域专家之间进行更密切的合作，可以形成一个强大的力量。

(banq注：因时间有限，直接在google翻译上进行调整，翻译不到之处请谅解。)