论文摘要

    2014年12月，本人所在的深圳市XX科技有限公司启动了一个销售过程管理系统的开发项目，本人作为IT部门程序组经理，担任了此项目的系统分析师角色。该系统主要用户为销售和售前技术人员。为销售人员提供项目机会的创建、项目机会跟进的功能。为售前技术人员提供项目机会协助支持功能。本文介绍了几种主要架构风格及特点，如调用返回风格、独立构件风格以及仓库类风格，论述了该项目在软件架构选择过程中，为何选择了三种风格的组合。最后，文章总结了采用该组合风格后带来的好处及缺点。

论文正文

背景介绍

    本人所在的深圳市XX科技有限公司是一个本土的电子元器件分销企业，主要业务为代理销售来自欧美、日本等多个品牌的电子元器件，公司有10多个办事处，200多业务员及60多个技术支持人员分布在全国各主要城市。 公司主要业务为将国外品牌的电子元器件通过项目协同设计的方式分销给国内的制造企业及设计公司。销售过程管理是公司核心业务流程，高层对此非常重视。2014年12月，公司启动销售过程管理系统（内部名称为COP系统）的开发项目。该系统定位于公司内部客户服务人员的协同作业平台，主要用户为销售和售前技术人员。系统为销售人员提供 项目机会的创建、项目机会跟进功能。而对于技术人员，提供项目机会协助支持功能。如何鼓励大家更好地服务有价值项目，同时避免资源过度集中，以实现公司整体价值最大化正是本系统着重要解决的问题。本人有幸在该项目中担任系统分析师角色，全程参与了该系统的需求分析、架构设计、系统开发及上线工作。

主要架构风格介绍

    在基本需求确认后，我们开始了系统架构的选择。我们首先考虑到的是调用返回风格，在该类风格中，最典型的是主程序、子程序风格，该风格应用广泛、曾经作为结构化开发方法的主要选择，具有结构清晰，维护方便的特点，缺点是主子程序划分缺乏标准，较难实现不同设计人员间设计的子程序复用，该类风格中另外两个面向对象及分层架构，面向对象在类的层次实现高度内聚，整个系统通过不同类的组合调用实现不同功能，便于类的复用，只是面向对象是一个通用风格，类的划分不同设计人员设计结果有很大不同，对实际架构设计指导意义不大。分层结构将整个系统按照抽象层次不同分为多层，每个层次的程序只需要负责与相邻的上下两层打交道，简化了系统中调用关系复杂度，随着一些成熟框架如SSH的流行，分层架构也得到了广泛的应用。

    接着我们评估了独立构件类风格，进程通讯架构风格和事件驱动架构风格。进程通讯架构将系统建设成一个个独立构件，构件间采用命名的消息传递来实现沟通与协作，事件驱动架构风格与进程通讯风格类似，也是将系统分各个为独立的构件，不同的是不同构件间通讯不采用命名的消息，而是采用隐性调用的方式，先将一个个构件的过程注册到某个事件中，当这个事件发生时，所有注册到该事件的过程自动被触发执行。这类风格的好处是独立构件间耦合度进一步降低，方便构件修改及替换，缺点是触发事件放弃了对被触发执行程序组的控制。

    我们还评估了仓库类风格，作为仓库类风格中最主要的数据库系统，有着非常广泛的应用，透过一个共享的中央数据库，保存当前系统的数据状态，其他独立的数据处理单元，分别对数据进行包括增删改查的操作，中央数据库管理系统透过自身机制如数据排它锁，共享锁等，实现数据高速访问，数据一致性，数据完整性。同时各独立数据处理单元之间互相不受约束。超文本系统和黑板系统作为仓库类风格中另外两种，相对来讲应用已经不是那么广泛，超文本系统主要应用于静态网页，黑板系统由一个作为全局共享数据的黑板，一个控制单元和多个知识源组成，主要应用与专家问题解决系统。

架构风格选择

    结合我们公司需求和系统环境的实际情况，最终我们选择了分层架构，事件驱动，数据库系统这三种风格的混合模式。

    首先我们为了安装方便，采用了B/S架构，整体上将系统分为页面表现层，业务逻辑层及数据持久层这三层。表现层采用jsp文件实现，业务逻辑层为一组java service，数据持久层采用mybatis xml文件实现。

    实际业务需求调研时我们了解到用户在多个地方有审批需求，比如业务机会阶段变更到2阶段时，项目名称修改时，及项目非正常关闭时，考虑到可能还会有其他地方需要审批，而审批是一个比较独立的功能模块，有自己的一系列行为，审批功能可能也会随着外部比如OA系统升级而做修改或替换。所以这里我们采用了事件驱动架构，将审批功能分装成一个独立构件，将启动审批流程过程注册到审批事件中，各个需要的功能界面只需触发审批事件即可。

    在数据持久层，由于我们公司ERP系统采用的是Oracle EBS, 所有数据保存在Oracle数据库中，而销售过程管理系统与ERP系统大量基础数据如客户，联系人，产品等是共用的，而且销售过程管理系统产生的项目，机会，服务记录等数据又需要回到ERP数据库以供报表系统使用。所以我们采用了将销售过程管理系统数据直接保存在ERP数据库中的作法，与ERP其他模组数据用不同的scheme分隔开，需要共享的数据用数据库中的授权完成。方便共享访问同时又保证了数据安全性。对于公共池，考虑到很多人需要在这里做交互，领养、弃领、维护、查看等很频繁，所以我们将各类公共池在数据库中建成独立表，方便快速数据交互。

总结

    项目耗时4个月时间最终成功上线，上线后得到使用单位用户和领导的高度认可，至今使用已经超过两年，后期维护过程中，用户单位由于业务分工及组织架构调整，项目池要求由原先的按照行业来划分修改为按照地区来划分，由于我们将项目池分类定义在数据库系统中，所以我们很快地就满足了用户的修改需求。另外，我们发现到采用该混合架构也存在一些缺陷，比如B/S分层架构带来的页面查询性能不佳，随着数据量的增加，首页刷新时间一度增加到8秒以上，针对这个问题，我们后来将首页分成几个块用多线程的方式分别独立刷新，现在速度提高至3秒左右。

    通过这个项目，本人更进一步了解到系统架构设计的重要性，也意识到各类架构风格只为满足核心业务场景系统需求的本质。