《分析模式》2024中译本-第1章（片段）

DDD领域驱动设计批评文集

做强化自测题获得“软件方法建模师”称号

《软件方法》各章合集

---

写在前面

仅提供少许片段，完整内容敬请购买《分析模式》2024中译本。

红色字体标出的文字，表示我认为之前的译本可能会让读者产生误解的地方。

感兴趣的读者，可以对照之前译本以及原文，捉摸一下为什么要标红。

主要原因当然是错译漏译，除此之外，还有：

*让读者对原文产生误会。例如，“主题区域”，有的译本翻译为“主题域”，会让读者误以为原文是subject domain，其实原文是subject area。

*不一致。例如，“上下文”，原文是context，有的译本译作“场景”。抛开会让读者误以为原文是scenario的问题不谈，后面的内容又把context译作“上下文”，这个就不一致了。

更细致的剖析，可以参见：

《分析模式》漫谈合集>>

类似问题，很可能2024中译本也会存在，请读者多多监督！

*****译文开始*****

1.1 概念模型

大多数关于对象建模的书籍都讨论分析和设计。对于这两项活动之间的界限在哪里，几乎没有一致的意见。对象开发中的一个重要原则是设计软件时使其结构反映问题的结构。这个原则会导致一个结果，分析和设计产生的模型都刻意地相似，导致许多人认为它们之间没有差别。

我认为分析和设计之间的差别仍然存在，但正在日益演变成侧重点的差别。在进行分析时，你是在试图理解问题。在我看来，这不仅仅是在用例中列出需求[8]。用例是系统开发中有价值的，甚至是必不可少的部分，但捕获它们并不是分析的终点。分析还涉及透过表面需求，得到关于问题机制的心智模型。

考虑一下，某人想要编写软件来模拟斯诺克比赛。这个问题可以用描述表面特征的用例来评估："玩家击打白球，使其以一定速度运动；白球以一定角度撞击红球，红球朝一定方向运动一定距离。"你可以拍摄数百个这样的事件，并测量球的速度、角度和运动距离。但仅靠这些例子可能不足以编写出好的模拟软件。要做好这项工作，你需要透过表面，去理解与质量、速度、动量等相关的运动定律。理解了这些定律，明白如何构建软件就变得容易多了。

这些定律是众所周知的，而且已经为人所知很长时间了，所以，像斯诺克球这样的问题并不常见。在许多企业中，与这些定律相当的基础机制并没有被很好地理解，我们不得不付出努力去发现它们。为此，我们创建一个概念模型——一个允许我们理解和简化问题的心智模型。某些种类的概念模型是软件开发的必要部分，即使是最无拘无束的黑客也会这样做。区别在于我们是否将概念建模视为一个独立的过程，还是将其视为整个软件设计过程的一个方面。

重要的是要记住，概念模型是人为的制品。开发人员用来创建类似斯诺克模拟的运动定律并不是真实世界的一部分。它们代表的是人类创造的真实世界的模型。从工程角度来看，它们是有效的，因为它们让我们更好地理解真实世界中发生的事情。此外，开发者可以使用多个模型。对于斯诺克模拟，可以使用牛顿模型或爱因斯坦模型。你可以争辩说爱因斯坦模型更正确，因为它考虑了球速引起的质量变化，因此更精确。然而，开发人员几乎肯定会更喜欢牛顿模型，因为速度如此之低，以至于对模拟的影响可以忽略不计，而使用爱因斯坦模型会增加许多额外的复杂性。这个例子说明了一个重要原则：模型没有对错之分，只看哪一个对手头工作更有用。

建模原则：模型没有对错之分，就看哪个更有用。

模型的选择影响最终系统的灵活性和可复用性。你可能会坚持主张开发人员应该使用爱因斯坦模型，因为所得到的软件足够灵活，可以处理涉及原子碰撞的问题。但这条路走下去就危险了。把太多的灵活性构建到系统中，会使其变得过于复杂，这是糟糕的工程实践。工程实践要求在制品的构建和维护成本与其所提供的特性之间做权衡。要构建适合某个目的的软件，就必须开发一个适合你需要的概念模型，在能应付的前提下，尽可能简单，不要添加你不太可能用到的灵活性。

最简单的模型不一定是你首先想到的那个。找到一个简单的解决方案需要大量的时间和努力，这可能令人沮丧。人们常常对一个简单的模型反应说：“哦，是的，这是显而易见的。”，并且会想"那为什么花了这么长时间才想出来？"不过，简单的模型总是值得努力的。它们不仅使构建变得容易，更重要的是，它们使将来的维护和扩展变得容易。这就是为什么即使现有的软件工作正常，用同样效果但更简单的软件替换它也是值得的。

如何表达概念模型？对许多人来说，概念模型内置于他们的软件语言中。使用这样的语言的优势在于你可以执行模型以验证其正确性，并进一步探索它。这个优势可不小，我在概念建模时经常使用Smalltalk。另一个优势是你最终必须将模型转换成编程语言，所以用目标语言建模可以省去翻译的步骤。（有些工具可以解释或编译分析和设计模型，从而减少与翻译相关的问题。）

使用语言的危险在于很容易陷入该语言的使用问题中，而忽视了你试图理解的问题。（对于更高级的语言，如Smalltalk，这个问题较小。我认识几位用这个语言来建模的有才华的概念建模人员。）用编程语言建模还有将模型与该语言绑定的危险。模型可能使用该语言的某些特性，而其他语言不具备这些特性。这并不意味着概念模型无法迁移到另一语言，但可能会使这个过程更加困难。