2. 如何保证系统的可扩展性、可复用性
明确、清晰的定义系统的扩展点 合理的扩展点的定义是建立在对业务的充分的理解之上的。可能一开始我们做项目时并不清楚系统有哪些地方是可能发生变化的,而找到可能变化功能的途径如下:
1). 根据自己的经验,主动的分析确定系统可能发生的变化;
2). 当用户主动提出需求的变化时,或用户自己也拿不准某个功能时,要考虑这部分功能是否应定义为一个扩展点,并提供当前用户认为合理的实现。
3). 当系统以产品的形式进行推广,不同的用户提出不同的需求时,考察系统是否能 “在不进行修改已有代码的前提下,通过增加功能实现并修改配置扩充系统功能”,从而对原有扩展点的实现进行替换,达到快速适应变化的目的。
而定义扩展点在系统架构上的实现方式,可以借助各种设计模式来做到,在以后的blog中逐渐介绍。
我们需要为我们的系统定义一份功能详细列表,格式参考下表:
当客户要求功能上的变化时,一开始可能大部分要通过修改代码实现变化,那么系统设计人员就得充分的考虑,为什么这种变化需要修改代码,如果把它定义为一个扩展点是不是更有意义。经过几个项目的积累之后,我们系统的扩展逐渐多起来,系统的可扩展性也得到了显著的提高。
当然,经过几个项目之后,我们也可能会发现有些扩展点是从来不变化的,那么就可以考虑这个扩展点是否多余,是否是过度设计造成的。
逐渐的我们的系统会呈现出一种“领域框架”的态势,如下图所示:
图中蓝色的部分,就是我们在某个行业内的积累,是对高层次业务的高度抽象,是公司所拥有的真正的财产,也是公司能够提供给客户的价值所在,是从一堆看似不断变化的功能中所抽取、沉淀下来的不变的东西,是不同项目之间可复用的部分。而图中黄色的部分,是系统可以灵活扩展的部分,是系统变化所在。图中绿色的部分,是系统面向特定客户时新加入功能实现,而它们中的有些功能,可能会最终沉淀下来,补充到系统的领域框架中去。