说说业务平台这件事

       今天看了国内号称最大的业务平台产品的白皮书，也有朋友见过他们公司的产品演示，反应是巨牛无比！以前写过一篇Blog，在回复中涉及到业务平台这东东，引起了gigix和o6z的一些看法，后来我就一直在关注这种东西。

       目前听说两个产品，见过一个产品。

       今天看到的这家公司可谓是理论与实践并重，ppt和白皮书都很有煽动力，如果我是客户我基本就投降了，不过我是搞技术的，多少有些怀疑态度。

     首先，其引用了Brooks的话，我想这话大家都很认同：

   Brooks指出：所有软件活动包括：
   根本任务——打造构成抽象软件实体的复杂概念结构；
   次要任务——使用编程语言表达这些抽象实体，并在时间和空间内将它们映射成机器语言。

   接下来其论证是：由于技术是软件活动的次要任务，而大多数企业级软件开发都是用编程语言code出来的，也就是都是面向那个次要任务，即使你把次要任务做成满分，也无法解决根本问题。

   在有限时间里，你既要解决次要问题，又要解决根本问题，从表面上看一定不如只解决根本任务好
   根本问题是一样都需要解决的，从表面上看，谁解决次要任务的时间短，成本低，谁就更好。
 
   之后，是证明其平台能力，什么类型的业务平台都能装配起来，并且其应用行业之广，使用单位之多，让人叹为观止。也可以说，这种方法确实不是纸上谈兵。

   其还强调了其思想不是搭积木，而是使用插件体系，把用户需求变成插件。这有点ESB的意味，但是，那个插件谁来编写，而这个插件里面的东西是什么呢？

  
   我比较关心的问题是：
   1、其如何解决企业级开发的重要、复杂问题。比如事务分割（一个原子性遇到复杂业务都是很难设计的），锁机制的设计（我在工行信息中心工作的同学天天受者DB2加锁的折磨）。莫非平台可以给我们一个万能的策略？某公司的基于流程自动配置的OA系统，就存在严重的事务并发问题。

   2、其如何解决企业级开发的重要、复杂问题。生产型企业系统的核心复杂性在于业务逻辑，而非工作流，莫非这样的系统只是填单，审批？而业务逻辑一定是个性化的。这种业务逻辑的复杂性，使不使用平台都要手工编，那么是不是在平台下更难编？

   3、其如何解决企业级开发的重要、复杂问题。DDD那本书强调企业核心复杂性是业务复杂，而解决之道是DDD，对此我颇为同意。我以为所倚思想及技术一定是OO。我看过的那个OA的流程定义，可以通过编写节点上的函数，来附加执行到那一步的业务（我觉得类似于JBPM的Action）。写些简单的小函数还行，如果是一个使用上千行代码才能实现的业务逻辑怎么办？（怎么可能有上千行的代码才能实现的业务逻辑？肯定是你的算法不优化。可惜，我做过的系统就是有那么复杂）如何测试这个方法呢？这个新添入的方法的事务如何控制呢？

   4、说说UI设计。企业级应用系统，不是简简单单填个表单就完事了，比如级联的下拉框（我们的界面需要5级联动，还要根据前面选择的数据向其他的标单元素填写数据），而且下拉框填充的数据是根据复杂的计算规则计算出来的。下拉框只是提供固定的几个选项的情况很少见，因为我们不是做OA，新闻站点，BBS。

   5、维护。我很担心前面提到的那个复杂的上千行的方法如何维护，或者我想错了，那个OA平台是那么做，用超牛的平台就不会这样了。或者你可能说，你不用平台开发，也可以把那个大方法拆成小方法嘛。这是我要说的第6点。

   6、使用平台是不是使简单的事情简单了，使复杂的事情更复杂了？

   或许是我多虑了，在观望，毕竟我现在也没用过。

        鉴于大家反复在寻求本文所指平台，本来已经在回复中写过，但是并未引起注意，所以在Topic中重申：

      我在这里讲的业务平台，不是J2EE这种底层的开发平台，不是ERP这种产品平台，而是介于两者之间的平台。这也是我今天看到的那个平台所说的平台。之所以会出现我想的那些东西，就是很多此类产品号称“程序员杀手”，其目标是要让使用它的人告别具体技术，所谓技术无关的业务平台。我的怀疑就在于此。