写在前面

今天开始，我们逐渐发布一些《分析模式》2024中译本的译文。

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

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

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

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

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

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

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

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

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

前言

不久前，还没有关于面向对象分析和设计的书籍。现在，这类书籍多到任何从业者都无法全部跟上。大多数这些书籍专注于教授一种表示法，提出一种简单的建模过程，并用几个简单的例子来说明。《分析模式：可复用的对象模型》是一本不同种类的书。它不聚焦于过程——如何做建模，而是专注于过程的结果——模型本身。

我是一名信息系统的对象建模顾问。客户请我培训员工建模并在项目上提供指导。我的许多技艺来自我对建模技能及其用法的了解。然而，更重要的是我的经验：我实际创建了许多模型，并定期看到问题重复出现。我经常发现，我在一个项目的许多方面又遇到了以前曾经面对的问题。这种经验让我能够复用之前构建的模型，改进它们，让它们适应新的需要。

在过去的几年里，越来越多的人也意识到了这个现象。我们认识到，典型的方法学书籍虽然有价值，但仅仅是学习过程的第一步。学习过程还必须要有实际构建的东西。这个认识催生了模式运动。参与模式运动的人多种多样，代表许多不同的兴趣和观点，但有一个目标是一样的：传播有用的软件系统模式。

由于这个模式社群的多样性，我们在定义术语“模式”时遇到了困难。我们都认为我们可以在看到模式时识别它，我们认为大多数情况下我们的意见会一致，但我们无法提出一个单一的定义。以下是我的定义：模式是已经在一个实际上下文中发挥作用的思路，并且可能在其他上下文中也会发挥作用。

我喜欢把这个定义留得十分宽松，因为我希望尽可能接近模式的根本动机，而不添加过多的限制性修正。模式可以有多个形式，每个形式都增加了对该种模式有用的特化（specialization）。（1.2节讨论了模式界的现状以及本书在其中的位置。）

本书讲述分析中的模式，这些模式反映了业务流程概念结构，而不是实际的软件实现。大多数章节讨论的是各种业务领域的模式。这些模式很难分类到传统的垂直领域（制造、金融、医疗保健等）中，因为它们通常在几个领域中都有用。这些模式很重要，因为它们帮助我们理解人们如何看待世界。基于这种认知来设计计算机系统——其实就是为了改变这种认知——是有价值的，这也是业务流程再造（BPR）所要做的。

然而，概念模式不能孤立存在。只有当软件工程师能看到如何实现它们时，概念模型才有用。在本书中，我介绍了可用于将概念模型转化为软件的模式，并讨论了该软件如何纳入大型信息系统的架构中。我还讨论了与这些模式相关的具体实现小技巧。

我写这本书的原因是，我在刚入行时就想读这样的书。建模人员会在本书中发现一些想法，帮助他们在新领域开始工作。本书的模式包含有用的模型、其设计背后的理由，以及它们什么时候适用，什么时候不适用。有了这些信息，建模人员可以调整模型以适应具体问题。

本书中的模式也可以用于评审模型——看看可能遗漏了什么，并建议一些可能带来改进的替代方案。当我评审一个项目时，通常会将我所见到的与我从以前工作中学到的模式相比较。我发现，意识到我工作中的模式，有助于我更容易地应用过去的经验。像这样的模式还揭示了超出简单教科书所能涵盖的建模问题。通过讨论我们为何以这样的方式建模，我们可以更好地理解如何改进我们的建模，即使我们不直接使用这些模式。

本书结构

本书分为两个部分。第一部分涵盖分析模式，即来自概念业务模型的模式。它们提供了交易、测量、会计和组织关系等领域的关键抽象。模式是概念性的，因为它们代表人们看待业务的方式，而不是计算机系统设计的方式。本部分的各章节着重介绍了可以使用的备选模式以及这些备选模式的优缺点。显然，对于工作在同一领域的人来说，每个模式都有用，但基本模式通常在其他领域中也有用。

第二部分聚焦于支持模式，它们帮助你使用分析模式。支持模式展示了分析模式如何融入信息系统架构，概念模型的构造如何转化为软件接口和实现，以及某些高级建模构造如何与更简单的结构相关。

为了描述这些模式，我需要一种表示法。附录简要讨论了我使用的表示法以及符号的含义。我没有使用单一的方法，而是倾向于混合来自不同方法的技能。虽然附录没有设计成技能教程，但它应该能够提供一个大纲并唤醒你的记忆。它还告诉你在哪里可以找到我所使用的技能的教程。

每个部分分为若干章。关于分析模式的每一章，都包含一些由一个松散的主题区域观念联系起来的模式。这个主题区域观念受到生成它们的项目影响。这个组织形式反映了这样的事实：任何模式都必须来自一个实际的上下文。在一章中，每个模式都有自己的小节。我没有像一些模式作者那样（见1.2.2节），为模式使用正式的标题，而是在合理范围内以尽可能接近原始项目形式的方式来描述每一个模式，并且只做最少的抽象。我添加了一些示例，以展示模式在其原始领域的使用，并暗示该模式是怎样有可能用在其他领域的。模式的最大困难之一是将它们抽象到其他领域。我遵循的原则是：这应该留给读者（参见1.2.3节）来做。

因此，与其说本书是一本从头读到尾的书，不如说它是一本目录册。我尝试在写每一章时，让它能独立于其他章节阅读。（然而，有时这是不可能的。当阅读某一章需要先阅读另一章时，我会在该章的介绍中说明。）每章都有一个介绍，解释该章的通用主题区域，概述该章中的模式，并说明模式起源于哪些项目。