剔除设计中多余的概念

软件设计首先要整理用户的业务模型，然后以此为参照，结合环境条件，建立软件系统模型。在这个过程中，很重要的一点是：要剔除软件模型中多余的概念。

哪些是“多余的概念”呢？如果一个概念是从用户的业务模型中无法直接观察到的，而是设计者推想出来的，那么这个概念就是多余的概念。

我们想象一个铁路公司，经营着ABCD四个城市之间的路线。这几个城市的位置如下：



铁路公司的老板想做一个售票系统，他找到一家软件公司。假设我就在这个软件公司工作，担任这个项目的负责人。铁路公司的老板这么对我说：从A到B的票价是50元，从B到C的票价是60元，从C到D的票价是30元，如下：



在这个基础上，两个城市之间的票价是各段之和。比如：从A到C的票价是AB+BC，就是110元。

于是，回到办公室里，我开始设计这个系统。我想：这个系统很简单，以A城市作为起点，把从A城市到各个城市之间的票价记录下来。就像这样，我设计了一个数据表，保存票价，他是这样的：

SQL>SELECT * FROM TICKET_PRICE;

CITY    PRICE
---------------
A       0
B       50
C       110
D       140

当旅客来买票，要从B到C去的时候，我们就用C的票价减去B的票价，得到从B到C的票价，得到60元。想从D到B，就用D的票价减去B的票价，得到90元。

这个设计非常简洁，看上去没什么问题。按照这样的想法，我们开始写代码了。但是，很快我就遇到了麻烦。

铁路公司的老板打来一个电话，他说：我们正在对票价做一些调整，从A到B的票价保持50元，B到C保持60元，但是从A直接到C的票价现在调整到100元。并且从C到A的票价要打一个8折，就是80元。

现在麻烦了，TICKET_PRICE这个表面临着重大的变动，所有基于这个表的业务逻辑都要改了。

烦恼的由来是什么呢？原因在于，这个设计是基于我的一个推论，而不是可以直接观察到的业务事实。直接观察到的业务事实是：A到B的票价是50元，B到C的票价是60元，A到C的票价是110元……而我在这个基础上做了一个推断：A到C的票价是AB+BC。当然，我做出这个错误的推断，有铁路公司老板的一部分“功劳”。无论怎样，变更不可避免，铁路公司和我，都必须承担这个错误的后果。铁路公司要追加项目投资，我们的开发成本要上升，而我自己，肯定要加班了。

这个设计中有一个多余的概念：A城市是一个基准点。这是一个在业务过程中无法直接观察到的概念，而我错误的将他作为整个系统的基础，让所有城市之间的票价以他们到A城市的票价为基准。

从业务中能够直接观察到的是什么呢？只有两个城市之间的票价。一个乘客来到铁路公司买票，从A到B是50元，从B到D是90元……他能观察到的只有这些，而没有作为某个基准点的A城市。系统的设计应该基于坚实的业务基础，而不是任何推断。“基准”这个概念需要从设计中剔除掉。

重新设计这个系统，应该用下面这样的形式描述城市之间的票价：

  A B C D A 0 50 110 140 B 50 0 60 90 C 110 60 0 30 D 140 90 30 0
当然，我可以用这样的数据表来保存这样的票价：

SQL>SELECT * FROM TICKET_PRICE;

START     DESTINATION      PRICE
---------------------------------
A         B                50
B         A                50
A         C                110
C         A                110
B         C                60
......

如果我一开始就这样设计的话，接到铁路公司的电话后，心里就会舒服多了。