说说业务平台这件事

       今天看了国内号称最大的业务平台产品的白皮书，也有朋友见过他们公司的产品演示，反应是巨牛无比！以前写过一篇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这种产品平台，而是介于两者之间的平台。这也是我今天看到的那个平台所说的平台。之所以会出现我想的那些东西，就是很多此类产品号称“程序员杀手”，其目标是要让使用它的人告别具体技术，所谓技术无关的业务平台。我的怀疑就在于此。

平台是我们软件发展的一个方向，目前WEB方面有EOS、楼上平台等，平台主要的作用是使软件有一个好的灵活度和伸缩性，使开发人员（应该主要是配置人员），在较知的时间里，来完成用户的需求变化。
其实，VS2005与JAVA等都是平台，对于开发人员来说，是简化开发细节的。不过，业务平台，是在VS2005或JAVA上，针对业务的进一步抽象，使之开发简化，应对各种需求变化。这点楼言主就不用多虑和观望了。

[quote="rihoonet"] 平台是我们软件发展的一个方向，目前WEB方面有EOS、楼上平台等，平台主要的作用是使软件有一个好的灵活度和伸缩性，使开发人员（应该主要是配置人员），在较知的时间里，来完成用户的需求变化。 其实，VS2005与JAVA等都是平台，对于开发人员来说，是简化开发细节的。不过，业务平台，是在VS2005或JAVA上，针对业务的进一步抽象，使之开发简化，应对各种需求变化。这点楼言主就不用多虑和观望了。[/quote]

 

这些我懂，不过我考虑的现实

关键是我们要对“业务平台”这个词语没有一个定义，这是个伪明题。

像你在文章中反复说的下拉框、UI，这些是业务吗，是与业务无关的东西剥离出来的一种框架解决方案而已，更不能说是平台中的特色吧。

就是工作流引擎，也是为了将流程定制、跳转与业务逻辑剥离出来的一种设计思想的实施。

表单定制更不是业务，也是与业务剥离的一种方式。

而在现实开发当中，做为一个有成熟技术积累的行业软件公司，这些都是个屁，根本不值得一提，早就有了，技术含量也高不到那去。在Delphi时代，他们就有了各种VCL组件、框架，功能比这强大多了，他们真正关心、头疼的不是这个。

在现实当中，真正影响我们，耗费我们大量时间的，对我们进度有很大影响的，就是在现实中复杂的需求，业务逻辑，这些复杂的需求，难以封装，造成复杂的设计、复杂的库表关系，这些复杂的设计，我们都知道越复杂的东西，越不稳定，更容易遭受到需求业务逻辑变化时的冲击。（希望那些做增删改查的人不要跳出来扯淡）

比如我们在分销系统时，所基于一种价格、库存模型，如果算法本身发了变化，有的时候，设计不慎，就会造成很大的影响，如果要过早的考虑未来的变化，妄图要封装未来、不可预测的逻辑变化，就变成过度设计，库表结构、程序结构都会复杂的很。

做为开发者，我们不可能去避免这些事情，只有依赖自己，我们只有不断的去积累，让自己对用户的业务理解的越来越成熟、深刻起来，不仅能剥离出非业务的技术，实现重用，更能将业务做成可扩展的框架。
比如我们做一个电业局时，我们的设计是一种的设计，我们的可扩展性，特别是针对业务的可扩展性，考虑是有限的，但等我们做到5个电业局的单时，我们遇到了更新的东西，我们对用户的业务，理解更深刻了，我们的设计就越来越成熟，我们再做下一个电业局时我们的变动越来越小。设计也是不断进化的，平台也应当是可进化的，你对用户的需求、业务把握的越深刻，你就越主动，不会背动跟着业务走，很多行业软件公司的constant，都是来帮助用户来规划业务、流程的，这就扯到信息化了，扯远了。

你还可以去了解一下金蝶的BOS平台，用友的U8所基于的平台，这是他们做财务、ERP的长期的业务积累，是他们在有中国特色的MIS，ERP的开发实施的经验积累，是吃了很多的亏，走了很多的弯路，所积累起来的，是给他们自己用的，不是给外人用的。

分层，Plug-in, component, framework, platform都只是一种分离粒度不同的技术手段，一种解决问题复杂度、降维的方式，而没有对业务的深刻理解，都是虚假的，而对业务最理解的，当然是你自己了，因为只有你奋站在用户的第一线上了，而不是那些厂商、Constant，他们只想拿到钱就走了，并且不要单心需求变化，因为他们所谓的平台，是和需求、业务没有关系的，而且他们吹嘘的就在此，那就是通用，只需要配置就可以完成一切，其实这是他们降低自己运营成本是一种方式，而不是真正的来解决你的问题。

所以我觉得，真正的业务平台，要有生命力，要依赖自己，在技术的基础上，要加强自己对用户业务理解的深刻度，从一开始就打造自己的业务平台内核，在一开始是不成熟的，但要去积累，用孵化的思想，去建设、壮大适合自己用的业务平台。只有自己的平台，才有生命力。

其实平台，就是抽象出很多业务特性而形成的（当然少不了积累）。当然，填报表单、增、删、改也是业务特性的一部分，都是业务平台要考虑的。然而，平台不能解决所有的业务需求，所以它会通过脚本（JavaScript等），来扩展与完善它不能实现的功能。

实现，都是靠平时项目的积累来的，多多看看别人的项目或业务平台是怎么解决你提的那几点问题的，然后将优秀的解决方案，结合到自己的平台中。你说到的维护比较难，那你说说你维护一段通用的代码比较好，还是维护多个项目的代码比较好呢？

can't agree more.

不知道楼上的为什么有这样的理解

[quote="OneEyeWolf"]关键是我们要对“业务平台”这个词语没有一个定义，这是个伪明题。 像你在文章中反复说的下拉框、UI，这些是业务吗，是与业务无关的东西剥离出来的一种框架解决方案而已，更不能说是平台中的特色吧。 就是工作流引擎，也是为了将流程定制、跳转与业务逻辑剥离出来的一种设计思想的实施。 表单定制更不是业务，也是与业务剥离的一种方式。 而在现实开发当中，做为一个有成熟技术积累的行业软件公司，这些都是个屁，根本不值得一提，早就有了，技术含量也高不到那去。在Delphi时代，他们就有了各种VCL组件、框架，功能比这强大多了，他们真正关心、头疼的不是这个。  [/quote]

 

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

       我参与过两个用Delphi开发的大项目，一个Form上有超多控件，页面流程超级复杂，各控件之间的关系也非常复杂，这其实也很头疼。

      你所说的表现层的问题我当然知道，只不过这类平台号称“技术无关”实在值得怀疑，企业信息系统每个环节都很费劲。

     用友，金蝶，易飞，易助的ERP系统我全都用过，因为我们学校是他们的合作伙伴。我的感觉是其实现的功能都很固定，与我本文中提到的平台不是一个概念。

     从我的发言可以看出，我所怀疑的，正是这些平台是如何解决我在过去的开发中遇到的核心复杂难题，比如UI设计，业务逻辑实现，持久化设计等等

[quote="rihoonet"]其实平台，就是抽象出很多业务特性而形成的（当然少不了积累）。当然，填报表单、增、删、改也是业务特性的一部分，都是业务平台要考虑的。然而，平台不能解决所有的业务需求，所以它会通过脚本（JavaScript等），来扩展与完善它不能实现的功能。[/quote]

   你还是没理解我说的，我文中已经提到了，可以通过某种其支持的语言进行扩展，比如那个OA用的是VB，文中提的那个牛平台用的是Delphi，这些我知道，对于它实现的原理我也理解，但是当你发现你还需要编码解决你过去就要解决的复杂问题（这些平台原本告诉我不需要），而且使用一种非常不好的方式，我在修改旧系统代码时，看到一千多行的函数，充满了条件分支和魔法数字，大段大段的重复代码，是多么的恶心。

    所以我说，这类平台是不是只是将简单的问题简单化了，对于复杂的问题依然提供复杂甚至是更加复杂的解决方案