haoxiaobo

从C到C++又到.net, 有一些心得, 和大家交流下...
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

业务系统设计要考虑的问题(二)分离业务逻辑服务层

Posted on 2011-08-31 20:21  HAL9000  阅读(1797)  评论(1编辑  收藏  举报


商业公司的业务同质化很高,市场如战场,谁能快一步应变,谁能给客户提供个性化,谁就得到了业务,谁就能生存。特别是象中国这样各地的经济、文化、政治极其不平均的国家,中央与地方的差异鸿沟巨大,地方特色必然需要。

但是站在总公司的管理角度上来考虑,当然是希望业务流程越规范越好,新花样总是意味着管理上的潜在危险。而对于总部信息技术部门的角度来看,个性化的新花样则是开发工作量的剧增、无止无尽的新需求。

管理与市场、领导与客户、全局与局部、总公司与分公司之间,这个思路方向性的矛盾是现实存在,而且不可避免的。

当然,最后项目还是要按上级的管理意图来实施,于是我们得到了一个全国一致的系统,一个唯一可用的UI,一本统一印发的操作手册。对于常规的业务,按着系统的要求操作就可以满足需要了。但是这个系统不再给机会进行业务、技术的创新,一切新的想法只能做为新需求向上级提出,然后由情绪恶劣的IT人员在程序里加入一个个 “if(strncmp(deptno, “BEJ”, 3) == 0)…” 这样丑陋到暴的代码来完成流程定制化。

 

其实要在同一个系统里同时满足总分公司双方的诉求,并不是不可能,就是把应用系统分为两层:业务逻辑与UI层,业务逻辑层是对业务逻辑的原子化,以实时服务的形式提供。在此业务逻辑服务的基础上,构建界面展现。

这里的关键点在于业务逻辑服务的提供,不仅可以是标准UI对其的进程内调用,也同时需要能够通过webserivce等协议提供进程外服务。对于标准流程,可以由总部来做“典型实现”,而对于有特别需要的分部,则可以方便在业务服务的基础构建业务系统的其他前端外延。

这样,从管理的角度上来讲,业务数据的进出都是通过标准服务来进行的,业务数据质量、业务一致性、合规性都可以通过统一的业务逻辑来得到保证,而分支机构则有机会为不同的业务开发不同的前端接口,以根据市场要求灵活创新。

这种模式特别适合于有外部合作机构的公司采用,如金融企业、电子商务企业等。如果业务系统只有一个UIIO方式,一切数据进出都要通过操作员来进行,那么与其他合作方进行自动化的数据对接就很难实现,一但有这样的需求,只能由交由掌握了底层逻辑的总公司IT从头开发。

现在我们的系统已经上线,可惜的是,系统采用了最简单最直觉的思路开发,几乎要把业务逻辑写在界面里了。事已至此,也不可能有什么改变了,这里只是我有过的想法分享出来,作为讨论。