迷途书童

敏感、勤学、多思
随笔 - 77, 文章 - 4, 评论 - 86, 引用 - 0
数据加载中……

面向领域的业务平台设计(一)

毕业后,做了很多年的中间件,有工作流,有数据持久层框架,还有个类似tomcat的server等,一直在思考,一个最适合业务的平台应该是什么样子的。因一直没有业务经验,因此,尽管有一些想法,但是也不知道这些想法靠不靠谱,最近一年参与了一个CRM项目的设计,积攒了一些业务经验,心中的想法逐渐清晰了起来,也有了一些底气,写下来跟大家交流探讨。

就如同变化多端的八卦卦象是由乾、兑、离等8个基本卦象组成,万事万物是由数种原子构成,形态各异的高楼大厦是由砖头和砂浆砌成,应用也有构成其的“元”,即构件。

业务应用是分层的,典型的分层是展现层、流程层、服务层、数据持久层,每一层次的关注点都不同,构件也不相同,比如一个业务逻辑层的构件输出的数据,会通过展现层的构件来展现在界面上。且各层之间的贯通黏合(如MVC中的Controller层就是黏合逻辑),通常要耗费比较多的开发精力,一个好的业务平台,除了在各层次分别提供可复用的构件,需要能够减少各层黏合的工作量。

面向特定领域的业务平台的易用度与其适用面是鱼和熊掌的关系,针对特定领域,要越易用,则平台能力就要越面向特定领域,则越不通用,导致适用面越窄。因此,一个好的平台,要注意分层,比如分成通用的构件和领域化的构件。业务用户可按需使用。同时,还需要在各层次开放定制能力,供业务用户在各层提供领域构件。

现在的产品交付都是解决方案级的交付,解决方案由多个系统或子系统构成,一个部门,一个项目组通常只是提供解决方案中的一个部件,负责端到端的业务功能中的一个环境,因此,需要支持构件的组装,以形成更大粒度的构件,支撑软件复用与集成。

开发一个子系统粒度的构件通常是一件很复杂的事情,如CRM,需求琐碎、变化频繁、不同客户要求不尽相同,如果缺乏一个好的支撑平台,人力成本会很高,TTM也会很长,因此,一个好的业务平台,也需要能够支撑快速的构件开发、定制。

解决构件的组装和集成,已经有比较成熟的技术了,如ESB、SCA等,IBM、Oracle等大厂商都有提供集成化的开发环境和执行环境。但如何支撑构件的开发这块,各大厂商也有支撑,比如在展现层,Oracle有ADF,在流程层,IBM和Oracle都提供了BPM,在service层,IBM和Oracle提供了规则引擎,VMWare的Spring,在持久层,Oracle提供了Toplink,还有就JBOSS大名鼎鼎的Hibernate。所有前面提到的这些都是业务无关的技术部件,且各层之间的靠业务开发人员自己来黏合,还是不够领域化。因此,一个业务平台,仅仅去重复制造IBM、Oracle造过的轮子,是完全没有竞争力的(这里不算成本)。面向特定领域,评判一个业务平台是否优秀的标准是:

1、是否提供了丰富的领域构件?

2、是否能够节省业务开发人员黏合各层的工作量?

3、提供了什么样的机制来应对需求变化?比如有的客户要求多加个字段、加个校验,有的客户要求少个字段、少个校验等等。

待续。。。

posted on 2012-02-26 15:04 迷途书童 阅读(1480) 评论(1)  编辑  收藏 所属分类: 随感系统设计java应用SOA

评论

# re: 面向领域的业务平台设计(一)  回复  更多评论   

企业应用是一块很值得研究的领域,但对个价值的实现是无益的。
2012-03-01 12:59 | 何杨

只有注册用户登录后才能发表评论。


网站导航: