消费信贷系统架构设计说明书.docx

消费信贷系统架构设计说明书.docx

《消费信贷系统架构设计说明书.docx》由会员分享，可在线阅读，更多相关《消费信贷系统架构设计说明书.docx（27页珍藏版）》请在冰豆网上搜索。

消费信贷系统架构设计说明书

宇信易诚消费信贷管理系统

——架构设计说明书v0.1

1概述

1.1文档目的

《架构设计说明书》用于确定消费信贷系统的整体架构，明确业务功能结构、技术方向、以及设计原则，为后续阶段进行概要设计、详细设计、编码开发以及测试提供方向性、原则性的指导。

消费信贷系统主要针对消费金融公司、银行消费信贷部门的业务运营需求而设计，本说明书将从消费贷业务特征分析为切入点，从业务架构、逻辑架构、技术架构等多个维度，逐步分析采用何种技术架构可以在最大程度地满足现有业务需求的同时，也能兼顾将来一段时间的业务发展变化。

1.2背景与建设目标

基于国整体消费金融业务的发展情况和银行关注消费金融的程度，以及国家加速发放消费金融牌照的趋势，为了能够抢占消费系统服务市场份额，特别研发新一代消费信贷管理系统。

消费系统建设整体目标如下：

1、建立先进、有效、多类型的进单渠道，并建立与渠道的沟通方式，以扩大与外部合作机构、消费者的联系和服务质量；扩大客户群体和异地服务的能力。

2、为了支持消费贷款业务短、平、快、业务量大等情况，建立适合的业务处理流程。

实现业务的精细化管理、统计分析、监测、审批、控制的电子化和自动化，提供存储、汇总、收集、反映，为各层次的经营管理者提供监控、决策、分析、预警等功能，为信贷业务的创新、经营决策提供充分的信息支持。

3、高效的影像审批流程：

通过消费信贷管理系统和影像系统的整合，以及通过系统提供在线通知、在线打印等自动化功能，实现业务审批模式的突破，满足消费业务集中审批、无纸化办公的要求。

4、智能的数据决策分析平台：

通过各种报表的展示和数据的统计分析查询，为不同层次的人员提供相应的数据，提高决策的效率和决策的效果。

5、标准外围系统接口和数据规则：

建立统一的外围系统接口，包括人行征信/公安身份核查/总帐接口等；建立导入/导出数据和模板标准，便于与第三方进行数据文件交换。

1.3设计规与约束

●Web容器（Servlet）JSR154规

●流程引擎遵循WFMC规

●规则引擎遵循JSR199规

●容服务器遵循JSR170、JSR283规

●基于宇信公司EMP平台进行构建，在遵循EMP的架构规的同时，在技术实现方式上接受EMP约束.

●流程引擎参照WFMC标准进行设计，与非WFMC标准的其它流程平台对接实现上存在一定的技术困难，需作为关注的技术实现约束条件。

1.4参考资料

《消费金融公司试点管理办法》

1.5述语

●个人消费贷款：

金融机构向个人客户发放的有指定消费用途的人民币贷款业务，用途主要有个人购物、住房、汽车、一般助学贷款等消费性个人贷款。

●CC：

客服中心系统。

●电核：

金融机构通过沟通方式核实借款人身份、贷款用途等基本情况。

●面签：

贷款审批通过之后，约客户到场签订借款合同、缴纳费用，向客户说明贷款权利义务。

●合作方：

指金融机构在营销贷款产品时的合作伙伴，如合作商户、大卖场、4S店等等。

●功能模块：

系统技术实现时，封装一类业务功能的组织单元，一个功能模块下有一个或多个功能组件。

●功能组件：

系统技术实现时封装业务功能与处理逻辑的组织单元，每个单元在概念上与业务过程中的业务实体基本一致，如客户组件。

●页面部件：

系统技术实现，用于在系统界面中展现业务要素的基本单元，如文本输入框。

2架构需求分析

2.1消费贷关键业务场景分析

2.1.1场景：

申请

消费贷款申请，是信贷类系统的典型场景之一，申请主要目的是为收集客户贷款融资需求与客户的基本信息，同时申请还需借助各种渠道来充分发挥其市场营销功能。

在消费贷的申请场景下，会有多种运作模式，例如由客户经理直接登录系统操作完成、由客户通过各种渠道操作完成、由合作商户通过各种渠道代理客户操作完成等等。

消费贷申请用例图如下：

图2-1

从上图中可知，消费贷申请过程中涉及到的角色有客户（申请人）、经销商（合作商户）以及客户经理。

客户可以从（银行本身或第三方）、终端设备发起贷款申请；经销商可以从终端设备、合作商户子系统（消费贷子系统）发起申请；客户经理可以从消费贷系统发起申请。

对客户、经销商与客户经理均可以通过系统查询申请的状态（其权限围）。

客户经理与后台自动任务可以对申请资料的合规性进行筛选。

消费贷申请，是整个系统的业务操作入口，其涉及角色、渠道多，情况复杂变数多，同时在消费贷下的不同产品申请时所关注的业务要素可能有较明显差异，系统需要充分考虑金融机构消费贷产品种类井喷时系统的应对方式。

由于涉及不少渠道是由客户主动填写并发起的，所以其数据量可能会很大，相应垃圾数据量也会很大，所以需要有人工与系统自动相配合的数据筛选功能，对大量申请数据进行甄别。

由于业务申请量可能较大，在设计时需要考虑尽量将录入工作从客户经理的日常工作中剥离出来，减轻客户经理重复工作量。

2.1.2场景：

电核

消费贷款电核，用于对客户身份与申请信息真实的核查，一般情况下，电核为金融机构的独立部门使用独立的系统（如CC）进行，消费贷款系统仅配合其完成电核操作即可，而不再去实现与CC系统相关的功能（如任务调度、座席管理等等）。

消费贷用例图如下所示：

图2-2

从上图中可知，消费贷电核过程中涉及到的角色有客户经理、电核人员与客户。

客户经理从消费贷系统中将资料提交至电核系统，同时也可以查询电核反馈结果；电核人员在电核系统中与客户联系，并将电核情况记录至系统中。

电核过程，对于消费贷系统而言是一个可选部分，不是所有消费贷产品都需要这一步骤，而对于没有类似CC系统的金融机构，但需要对客户作电核，则可以考虑直接作为系统业务流程的一部分来简化实现，即在消费贷中系统录入线下电核结果即可。

由于电核步骤涉及独立电核系统，所以在设计时需要充分考虑与电核系统间可能的交互模式，保证在接入不同的电核系统时，对消费贷本身业务流程的实现没有影响。

2.1.3场景：

审批

消费贷申请审批，也是信贷类系统的典型场景之一，审批主要目的是对客户的贷款申请，按金融机构规章制度的进行逐级审批。

不同金融机构、不同的产品其审批流程步骤、参与人员、以及审批规则将会有明显区别。

消费贷申请审批的用例图下如：

图2-3

从上图可知，参与审批的角色主要有客户经理与审批人员（如，其他客户经理、主管、风险专员等等），担当审批人员的角色不同机构、不同产品、甚至同一产品不同的申请（如，新件与复议件）都会有不同角色人员来完成审批工作，其完全取决与行的规章制度。

但无论审批角色如何变化，其需要完成的动作基本一至，主要包括对申请的同意、否决、打回或撤销等等。

在设计时需考虑消费贷审批过程的不确性，系统需要提供灵活配置功能来应对不确定的审批需求。

由于每天申请单量可能较大，需要在设计层面充分考虑如何提高审批工作效率，例如批量审批操作、自动审批、关键消息提醒等等。

同时，需要提供充足的审批统计数据，为行的审批流程优化再造提供数据分析支撑。

2.1.4场景：

面签

面签是信贷类系统的典型场景之一，面签主要目的是在审批通过之后约客户到场签订借款合同、缴纳费用，向客户说明贷款权利义务等等。

一般而言面签主要工作是在系统线下完成，线上主要合同打印、登记面签结果、确认合同已签即可。

但对于消费贷而言，对时间要求高，面签过程可能会直接在场外完成，以提高贷款的效率。

消费贷面签用例图如下：

图2-4

从上图可知，面签过程参与角色主要有客户、客户经理、合作商户（如经销商），如果在场签订合同，则客户与客户经理参与即可，如果在场外签订合同，则可能由客户、合作商户、与客户经理共同参与，也有可能在场外通过专用设备进行远程面签（如视屏面签），此时就不需要客户经理必须到场，仅需合作商户通过配合即可。

由于消费贷面签过程大多都是在场线下进行，但随着IT技术的不断发展，面签功能会逐步放在场外上线进行，系统需要充分考虑在新的面签模式下如何能很好的支持。

2.1.5场景：

还款计划与费率计算

由于消费贷大多数都是采用按揭方式还款，对灵活的还款计划计算的必不可少。

系统需要能支持各种方式的还款计划计算，以及相应的费率计算。

由于金融公司可能没有核算系统，所以系统中需要能提供部分账务核算功能；而对于有核算系统的银行，则需要实现与其核算系统的接口。

为此系统需要充分考虑如何支持有核算系统与无核算系统两种情况。

2.2消费贷业务特征

消费贷款产品与其他贷款产品相比，其基本特征是小额、快速与灵活。

在运作模式上主要特征是与特约商户合作推广业务。

在目标客户群体在主要特征是针对年轻人、年轻家庭以及由合作商户推荐的客户。

服务模式上，主要特征是IT自助型服务模式。

消费贷‘快速’这个特征最为突出，其中最快的贷款产品要求可以直接在商户卖场中1小时之完成，一般的消费贷款产品，要求在1~3个工作日完成。

而机构审批时间要求最快能在30分钟完成。

可以说没有什么贷款产品比消费贷对工作效率要求更高，这对于承载消费贷业务运营的IT系统而言，如何满足对高效率的要求将是一个挑战。

消费贷‘灵活’主要体现在还款方式、利率与贷款品种上。

由于消费针对的目标客户的用款需求十分明确，相对与信用卡（等其贷款产品）而言，还款方式与利率定价的针对性更强，对于客户而言享用金融服务的方式（如更适合自身条件的还款方式）也更为多样化，更灵活。

由于消费领域十广泛，与商户合作方式很多，对应的消费贷会衍生出很多产品，如针对耐用消费品的贷款产品、针对电子消费品的贷款产品、针对教育培训的贷款产品、针对汽车衍生品的贷款产品等等。

对于IT系统而言，需仔细考虑如何应对业务产品形态的多样化。

也许是由于年轻人更能接受超前消费的观念的原因，市面上已有消费贷产品面向的客户主要群体一般是年轻人，消费贷产品将来一定会考虑采用更有针对性的自动营销渠道，例如直接在网上商城营销、手机/PAD等终端设备上营销、微博营销等等。

对于IT系统而言则需要能支持多种的营销渠道来源，同时也能提供给客户更多享用金融服务的渠道，如通过手机/PAD等IT自助服务。

由于金融机构的消费贷产品未来发展，在很大程度上取决于对合作商户的不断发掘，对于IT系统而言，需要充分考虑如何应对不断增加的合作商与合作模式给系统功能带来的负面影响。

2.3设计目标与原则

消费贷系统作为一个独立、新兴的贷款类业务操作系统主要围绕着以下三个主要目标进行设计与建设：

1、系统能提升消费贷业务运作的效率；

消费贷业务对时效性要求很高，在设计时需要优先考虑，系统能提供哪些模式，让工作效率得到最大限度的提高。

提高用户在系统中的工作效率，首先是要有良好的UI设计，在UI设计时考虑能达到不同业务场景下突出不同的重点的效果，尽量实现‘消息驱动’的UI操作模式。

要提高效率仅仅从UI层考虑是不够的，更应该从优化业务操作流程着手，进一步考虑IT技术如何帮助业务流转加速，例如，自动化数据筛选、自动化审批、任务智能分配、大任务拆分、基于数据分析的流程再造等等。

除此UI与业务流程优化之外，在系统设计时需考虑提供相应机制，保障在业务高峰期的系统性能，尽量保证不会出现因为系统响应速度原因而影响业务效率，例如，合理的子系统划分、流量控制、支持系统的横向扩展架构等等。

2、系统能规业务流程、屏蔽操作风险；

消费贷系统作为业务操作管理类系统而言，能够监控与约束对机构人员的行为，屏蔽人为操作风险的发生，是最原始的初衷之一。

系统设计时，不仅仅把贷款的审批过程用工作流模式来实现，而是考虑采用其来实现操作层面的主线功能，通过在系统中构建各业务场景间流转逻辑关系，来实现业务规在系统中的落地。

同时，工作流模式还需要与风险识别与拦截机制结合起来，才能真正发挥规业务流程的作用。

3、系统能支撑消费业务的不断发展；

消费金融公司在国处于起步阶段，未来的变数还很大，其主要表现在新消费贷产品可能会大量出现，甚至会出现全新的业务模式。

现在所设计的消费贷系统，必须要认真考虑如何能适应将来较长一段时间（3年）的业务需求变化，至少要保证不影响业务的发展，同时，尽量能缩短未来新产品的落地开发周期，不影响新产品的投放时间。

3架构设计

3.1系统业务架构

消费贷业务不同于传统的个人消费类贷款，其有着更灵活的业务运营方式，下面将从业务模式、业务流程、功能划分三个部分来分析消费贷业务的架构。

3.1.1业务模式

消费贷的业务模式与传统的个人消费类贷款、以及个人信用卡相比，最大的不同就是营销渠道的不同，采用现场主动营销方式，即直接在客户消费场所营销，而不是被动地等着客户上门来贷款或者刷卡消费。

为此，消费贷的运作需要合作方支持，业务模式见下图：

图3-1

在传统贷款方式下，客户的贷款需直接面向金融机构的，而消费贷是通过在合作方（如卖场、4S店、培训机构等等）的主动挖掘需求。

在成交之后，金融机构直接将货款打给合作方；客户方分期向金融机构还款；金融机构在一定条件下，定期付给合作方一定的佣金。

在这种模式下金融机构赚取了利息与手续费、合作方扩大自己的客户群并能赚取一定的佣金、客户则提前买到了合作方的产品或服务，实现了三方的共赢。

在这个模式下，对于金融机构而言，最重要的是如何找到合适合作方，且能尽可能多地扩展新的不同领域的合作方，同时提供合作方感兴趣的激励机制（如佣金等等）；对于客户则能提供更有针对性的还款方式。

3.1.2业务流程

消费贷在业务流程上与普通贷款在本质上没有太多区别，其目地都是为了实现审贷分离。

区别在于消费贷为提升效率，流程中各节点专业性更强、分工更明确，即采用类似信贷工厂的模式（注：

消费贷并不是工厂模式）。

业务流程图如下所示：

图3-2

消费贷业务流程中，电核为可选节点，有的机构或产品不需电核这一步骤，其它步骤均会必选步骤，面签为线下节点，今后可能会放至线上。

申请节点，由客户经理或客户填写并发起；电核节点，由独立的电核人员完成对客户的核实；审批节点，由管理人员完成对申请的审批；面签节点，由客户经理与客户一起完成的同合的签订；放款节点，由财务人员完成打款操作；还款节点，由系统自动完成从客户还款账户上扣款，或客户主动发起提前还款。

随着业务量的增大，今后可能会出现无法满足对放款时限要求的情况，届时将考虑将上述流程中部分业务外包出去，例如申请与电核。

同时，尽可能采用自动流程部分代替其中的人工操作。

3.1.3功能划分

消费贷系统主要面向独立的金融机构，一般其核心职能会划分到四个子部门：

产品管理部门、风险管理部门、营销部门、财务部门。

对应图3-2中，申请、面签交由营销部门中的客户经理完成，审批由产品管理部门与风险管理部门负责，放款由财务部门完成。

具体消费贷功能划分如下：

图3-3

消费信贷业务功能由五个部分组成，包括业务受理子模块、贷款业务流程处理和管理子模块、帐务模块、报表子模块、业务监控子模块，其包含了完成消费主体业务所需的全部功能。

各子模块完成专项工作，如受理模块主要完成营销和渠道进单功能；业务流程处理和管理模块主要完成金融机构部对业务的所有业务处理，包括电核、人工审批、放款、贷后管理、催收和保全；帐务模块主要完成贷款或卡业务的各种帐务计算，包括还款计划生成、利息/贴息计算、罚息计算、复利计算、费用计算、佣金计算等；报表模块主要完成对所有业务分析、流程分析、客户分析、风险分析等统计和展现；业务监控模块主要用于对业务的实时业务量监控。

3.2系统逻辑架构

消费贷款系统功能从逻辑上划分成六个层面——业务操作层、业务管理层、业务工具层、决策分析层、账务核算层以及技术支撑层。

功能逻辑结构如下图所示：

图3-4

3.2.1功能层次划分

●业务操作层

在业务操作层中的功能用于直接面向客户的业务操作与呈现，可以简单地认为其相当于系统的面门，用作信贷基层人员对最终客户的业务门面与操作入口。

其中包括业务产品线、合作方两大部分。

产品部分以业务产品为基本组织单位，其承担着一个产品在生命周期所有对外的功能。

之所从在概念上与物理上将这一层分离出来，一方面能将系统功能与现实中的业务角色功能映射上，减少现实业务与虚拟系统之间在基本概念与组织结构上的差异；另一方面也是因为在业务操作层面上，业务形态丰富、变数大，期望通过架构上的分离，来确保系统能适应这种特性，不会因为新业务的加入而影响已有业务。

可以说业务操作层就是整个信贷业务的外延。

●业务管理层

在业务管理层中的功能用于对业务操作层的支撑与管控，可以简单地认为其相当于中后台，用于中、基层管理人员对业务运作的监控与管控。

本层以业务生命周期过程中的业务实体为基本组织单位，其承载着各业务环节的管理、配置、监控、以及对应业务实体的基本功能（与现有划分基本对应），并为业务操作层提供具体功能服务。

由于采用业务实体为功能单组织单位，其相对操作层而言是稳定的，这是因为业务实体作为业务生命周期中承载业务要素的介质，其种类个数是一定是可穷举的，其在不同贷款业务间是相同、相似甚至是可共用的，并且在不同银行间之也是相似的。

而相对于业务操作层面，业务产品种类个数（尤其是对未来新产品）是不可预期的，不同业务产品间使用的业务实体也不会相同，更重要的每种产品的运作模式都会完全不同，不同银行间产品的运作模式也有明显差异。

可以说业务管理层就是整个信贷业务涵。

●业务工具层

在业务工具层中的功能，用于为业务操作与业务管理的正常运作提供必要的专业的工具箱，但其并不对业务运作的形态、业务规则或流程产生直接影响。

同时，业务工具是完全可以与的业务操作、管理相分离的，甚至可以替换成第三方独立系统。

之所以划分出这一层，主要原因是为银行部对专业化技能的要求越来越高，随着银行自身的发展，会形成越来越多专业职能岗位（或部门），或者干脆将部分非核心的业务操作外包给第三方。

独立的工具层，可以与银行机构组织职能一一对应上；同时，也有利于在核心业务与非核心业务之间划分出一条明显界线，从架构层面去减轻两者间的耦合程度。

●决策分析层

在决策分析层中的功能，用于对业务运营过程中产生的数据进行统计分析，例如，对业务办理效率分析、对贷款人群分布分析、逾期贷款占比分析等等。

决策分析层中，主要通过日终批数据加工处理、报表工具来实现对数据的分析与展现。

由于数据分析不是现阶段消费贷系统的关注的重点，因此，独立划分出决策分析层，有利于保持核心功能的稳定性。

●账务核算层

在账务核算层中的功能，用于为没有核心业务系统的金融机构，提供一个Mini版的核心业务系统，其只含贷款功能，不含存款功能（注：

与银监管会相关策略吻合）。

其能完成贷款发放、还款扣款、罚息减免、贴息处理、减值计提、贷款形态转移等基础的账务核算功能。

由于不是所有金融机构都没有核算系统，所以将本层独立出来，保持其与它层次间的独立性，有利用增强产品的适应能力。

●技术支撑层

技术支撑层，用于为消费贷系统提供基础开发平台与运行容器，是所有业务功能落地的基石。

其中包含的EMP容器、流程引擎、规则引擎、报表引擎与数据访问工具等等。

本层将在后继章节进行详细介绍。

3.2.2功能层次关系

消费贷款系统中六层功能之间是一个逐层依赖的关系，如下图所示：

图3-5

消费贷系统本质上是一个业务操作系统，业务操作层自然便成为了整个系统的主要门户，是所有业务的入口。

业务的正常运营，离不开业务管理部门（风控部门）的管控，与专业部门（例如，财务部门、产品部门、客服部门、IT部门等等）的大力支持。

因此，业务操作层依赖与业务管理层、业务工具层、账务核算层以及技术支撑层。

业务管理部门为了能更好的对业务进行管控，也需要专业部门（如产品部门、财务部门、IT部门等等）的积极配合。

因此，业务管理层依赖与业务工具层、账务核算层与技术支撑层。

金融机构财部门是一个相对独立的部门，其完全依照财务规章制度运行，一般而言，其运营主要有IT部门的支持即可；同时，由于不是所有金融机构都需要消费贷系统提供核算功能，这就需要尽量保证其独立性，因此，账务核算层，只需要依赖技术支撑层。

决策分析主要是针对数据的统计分析，因此，其仅仅依赖与技术支撑层，而对于其它功能层次，也均不直接依赖于决策分析层。

3.3系统技术架构

3.3.1子系统划分

消费贷系统按功能职责划分成四个子系统——消费贷款管理系统、消费贷款合作方系统、消费贷款核算系统、消费贷辅助系统，如下图所示：

图3-6

●消费贷款管理子系统

消费贷款管理子系统，主要面向金融机构部的客户经理以及相关管理人员，负责完成消费贷款进件流程与业务管理。

其中包含了逻辑架构中的业务操作层、业务管理层、业务工具层中的绝大部分功能（注：

不含操作层中的合作方功能），例如，贷款申请、人工审批、合同管理、放款等等。

消费贷款管理子系统是整个系统业务运营的核心系统。

●消费贷款合作方子系统

消费贷款合作方子系统，主要面向金融机构之外的合作机构，如卖场、4S店、培训机构等等，其负责为合作方与金融机构之间建立渠道与门户。

其主要功能是进件处理与审批状态查询。

之所以将合作方独立成子系统，首先，是出于金融机构与合作方之间合作方式存在不确因素的考虑，例如，现在是对卖厂、对4S店，但今后可能会对网店、对PAD、对外包公司等等，因此将合作方的功能独立出核心业务系统，作为系统对外扩展的网关，会有利于消费贷的不断发展；其次，是出于安全方面考虑，由于需要直接面对互联网，所以必须将对外的功能独立部署，屏蔽任务从互联网上直接访问至核心业务系统的渠道。

●消费贷款核算子系统

消费贷款核算子系统，主要面向金融机部的账务人员，负责完成所有与贷款相关的账务处理，如贷款发放、还款扣款、罚息减免等等，其与逻辑架构中的账务核算层相对应。

独立的核算子系统，有利于增强系统的适应能力。

●消费贷款辅助子系统

消费贷款辅助子系统，主要负责完成数据加工与分析、定时任务调度、报表生成与展示、历史数据查询等后台任务。

之所以划分出辅助子系统，主要是出于对系统性能的考虑，通过独立部署的子系统来完成后台任务，避免后台任务对日间业务运行效率产生不良影响。

●子系统间依赖关系

消费贷款四子系统之间的依赖关系如下图所示：

图3-7

合作方子系统的运作必须依赖与管理子系统的支持，合作方子系统负责对外渠道，其独立运行没有任何意义，需要通过管理子系统来完成对每笔进单的业务处理。

管理子系统的运作，需要有核算系统的配合，核算系统可以是消费贷系统嵌的核算子系统，也可以是机构的核心业务系统。

管理子系统通过核算子系统完成所有贷款账务相关的业务操作。

辅助子系统的运行，需要依赖管理子系统、核算子系统的正常运行，辅助子系统用作消费贷系统的后台处理单元，其独立运行没有任何意义，需求通过调用管理子系统与核算子系统中的业务功能来实现自身功能。

3.3.2技术选型

消费贷系统是基于JaveEE的WEB应用，其后台技术框架采用公司EMP实现，前台业务展现框架基于Jquery+EasyUi实现，具体如下图所示：

图3-8

消费贷系统基础支撑环境为JavaEE以及在此之上的WEB容器中间件（如WAS、Weblogic等等），对Java虚拟机版本要求为1.5或1.6，对WAS版本要求为6.1以上（含），对Weblogic版本要求为10g以上（含）。

技术基础框架采用公司产品EMP2.2，流程引擎选用公司产品eChain2.2，规则引擎shuffle1.0；业务处理逻辑实现，采用组件注入机制与POJO为业务数据结构方式；业务展现逻辑基于Jquery实现，页面部件基于EasyUI实现，并用JspTag包装，前后台通讯有使用Ajax方式。

业务逻辑处理没有选用EMP提供的标准开发方式实现（逻辑流+KCOL），而是选择了组件+Pojo方式实现，由其是在数据结构上不再使用EMP的KCOL，而是选择传统的Pojo方式。

这是因为，希望通过功能组件+Pojo方式来实现面向对象设计思路，不再去走面向过程+快捷开发的老路。

这是因为消费贷系统是业务操作类系统，其中的业务运行模式、信息结构都是具有积累价值的，所以可以用面向对象的设计思