业务构件重用，圣杯还是神话?

这两天有点走火入魔。思考业务构件的重用可能性有多大。

我进本公司刚三个月，公司主要面向交通行业，主攻公路勘察设计院信息化这一细分市场,作了有几年了,既然作的是管理软件，实际上对技术的要求并不高，由于IT人员的高流动频率，公司的业务知识积累很难有效传递给开发人员，即知识管理上非常欠缺，结果是，处于低水平重复的恶性循环，很难为客户提供高质量的产品和服务。

象我公司发展到这个阶段，应该达到了以“二次开发模式”为主，即在该领域的多次开发后，产品原型已提炼出来，在这个基础上，再给后来的客户作少量个性化定制开发。当前最迫切的是，将这个“原型”以怎样的形式描述和保留，抽象到哪一个层面上，我觉得到领域模型这一级就足够了，抛开数据库的困扰，先建自己的商业对象库，以适当的粒度切分，uml图为主，辅以文档，描述接口及上下文存根，适用环境等，这些是真正能让开发人员迅速理解和复用的精华所在。下一个项目，准备增加这种意识,在实践中摸索和进步。

将来的发展是考虑MDA或者业务构件复用。我想来想去，真正好复用的构件始终是"技术"构件。所谓业务构件，也仍然是程序代码段，积累再多，也不能有效应对业务敏捷变化。还真是头大呀，少量业务非常明确的模块可能会形成“构件”，如用户权限管理，工作流。唉，洗洗睡了。