这是一个老爷爷系统。

上一篇谈到统一的系统特征描述的形式问题。觉得“功能”或者“领域模型”可能可以承担这个重任。

但功能和领域模型都不能直接使用：

• 功能的问题是很难跟代码直接关联起来。
• 领域模型的问题是只有开发同学熟悉这个概念。SA、测试、开发经理等同学比较熟悉的是“功能”这个概念， 虽然他们对这个概念的定义不尽相同。

我们希望我们的特征描述既可以将各方面关注点都联系起来，又可以让各方面都工作在自己熟悉的概念上。 于是我们尝试使用一种二者的混合体。

• 从领域模型出发，以便我们能跟代码产生联系¹。代码非常重要，因为在运行时，代码决定的逻辑基本上是系统的一切。
• 弱化领域对象的定义，只描述它是否存在和与其他对象的关系²。领域对象的定义显然是重要的，但我们现在要的是“框架”。
• 强调领域过程，弱化领域实体。实体常常被认为是分析的结果，看上去和“功能”没有关系，有些方面的同学不关注。
• 领域过程之间的关系划归为三种：Include、Extend、Generalization³。
• 领域过程与实体间，只有一种，引用关系。实体与实体间的关系，不再描述。

总的来说，这是领域模型的一种裁剪，或者可能更准确地说法，是一种遮挡：暴露大家的共同关注点，隐藏其他。

（再下篇继续）