引子：企业级应用快速开发在业界不是一个新话题，对于作者8年多的职业生涯而言，更是一个持之以恒、孜孜不倦寻求解决方案的课题。最近，该课题有了新的进展，在重构企业融资服务的大背景下推出，尤其有意义。
背景
作者多年来一直从事银行对公融资类产品的研发和实施。在此过程中，很多问题需要思考和改进，归纳了一下，大概有如下几个对于软件活动具有重大意义。
ü 软件产品研发过程中，需求实现的颗粒度保持到什么程度，对于项目实施的意义更大?
ü 软件活动中，应注意哪种资源的积累最有意义?
ü 如何才能做到软件设计的相对通用性?
ü 如何做到对软件产品研发的批量化?
ü 用户需求快速处理的意义?
ü 面向行业的抽象对于批量客户化的意义?
ü 技术上实现低配置无限横向拓展的意义?
对技术的理解
“技术是为了业务实现而服务的。”
相信这句话，所有的软件工程师都没有异议。因此用户需求是第一位的，能实现用户满意的功能是技术存在的意义所在。而与用户的不睦恐怕都源于技术的匮乏，或者说没有做好充分的技术准备，项目就上马了。
过分的依赖技术也不可取，毕竟精力有限、资源有限，无限的技术更新将耗费大量的理解用户需求，与用户沟通的宝贵时间，同样不能最大限度的满足用户需求。
这里，对技术的使用要有一个度字。
对需求的理解
“需求是按照行业来区分的。”
这句话是工作多年才能总结出来的。请诸位仔细回购一下自己做过的项目，尤其是有多个行业经验的工程师，用户的需求虽然可以分为不通的模块，但在实现上是否都可以提炼和抽象。从前台展示、前台操作、后台服务等特性进行总结，你会发现，如果你有很好的设计，其实你可以做到相对通用性的。(当然，如果没有做到相对通用，不能说明你的水平不够，而是你们公司没有给你时间，项目进度太紧张了。)
所以说，在软件实施过程中，一定要抽象总结用户需求。
软件架构模式
“mvc是纯技术模式，应该扩展至业务范畴”
曾几何时，”mvc”是软件设计先进性的标志，诚然，对于开发人员而言，在此模式的大原则下，业务被一定程度的模块化，面向对象的设计方式能够帮助运维人员直观的理解系统、维护功能。事实证明，后台逻辑和页面操作控制逻辑的过度客户化将使系统过分复杂，控制层和服务层设置页面操作控制函数都出现了业务逻辑代码，以此代码进行再实施将会是灾难性的。
所以，软件设计模式应该是：功能层(f)+服务层(s)+控制层(c)+视图层(v)
宝贵的资源积累
“保证 视图层、控制层、功能层的抽象性，业务逻辑体现在服务层 ”
伴随着项目的实施，根据不同的业务展现习惯，视图层会越来越丰富;而不同的操作习惯会积累不同的操作定义;因为业务处理要求的不同，服务层也形成了积累。这些积累都需要通过“视图配置”、“操作配置”和“服务配置”录入平台，以便可以通过“功能配置 ”展现系统。