一、从EOS 开发说起
目前XXX行信息管理类系统使用普元EOS7.5 开发平台，基于构件的开发，模块化，独立部署。Primeton EOSTM，是全球领先的SOA应用平台。作为成熟产品，有很强烈的兼容并包意愿，主要原因是他试图解决的问题比较复杂，也很广泛，而对于这一问题的解决方案又有很多种，尤其是有很多开源软件，无法穷举。
优势：
1. 图形化：逻辑流是EOS产品的一个核心组成部分，用图形化的方式来描述业务处理逻辑，即用"画图"的方式来"写代码"。逻辑流可以使用图元控制事务、循环、调用运算逻辑、调用服务、调用子逻辑流和处理异常等操作将小粒度的运算逻辑组装成业务逻辑。学习成本低，入手快。
2.异步调用：图形化（拖拽式）开发业务逻辑，最大的用处是处理异步的逻辑，例如调用一个 WebServices，同步调用时如果被调用方很慢，当前的线程也会被挂死，异步就没有这个问题，至少还能够超时释放（这里比较复杂，就不细说了），但是异步的代码写起来很复杂，要写成回调方式，这样代码的可读性就非常差（试想用回调方式调用 3 个 WebServices的代码结构），这样用图形化就比较简单，执行时会变成异步的。
3. 工作流: 普元EOS的工作流性能非常强，功能上对外接口特别丰富，加上直观的展示，得到很多认同。
争议：
1. EOS中争议最大的是拖拽式开发业务逻辑（也就是说的可视化开发）,我们设计时即可以用拖拽式开发，也可以用spring bean的方式写代码开发业务逻辑。基于JAVA做应用架构的方式很多，这也是有很多开源软件的原因，仁者见仁智者见智。
2.可视化开发另一个特点是重复动作多，特别是碰到配置报文的场景，会让你傻傻到盲目。如果碰到有表结构变更的，字段变更的，也是比较难言的调整。
3.还有一个情况是有的复杂交易流程画了满屏，也是很感人的，维护相当的痛苦。
4.初级开发者觉得很好用，业务主键方便，也确实可以不用写代码，通过拖拉拽实现业务逻辑，不可否认，入门容易。那进阶呢？这就考究硬实力了，所有的东西，简单的都容易理解，简单的东西叠加，或者碎片化之后，再去理解，就要花心思了。EOS可视化开发最终运行也是通过引擎，编译成class 代码执行的。从概率论角度讲，做得多错的概率也越大，比如假设单行代码的成功率是4个9，即0.9999是单步的成功率，后面是代码行数: 0.9999^1000=0.905 ; 0.9999^10000=0.368。
二、扩展，软件开发理念
EOS既然试图解决JAVA的应用架构，就不可避免的要有自己的理念，这些理念未必大家都认同，也是开发者争议比较多的问题。移动互联网的快速发展，造成了应用技术的井喷，各种概念频出，框架、中间件繁多，场景代入的解决方案多种多样，软件思想也是层出不穷。
我们暂且抛开这些干扰，回归程序的原义，本质。程序是一种既定的规则，在计算机中就是一段按人的思路设计在计算机上执行的代码。通常来说，软件开发经历了下面三个过程：
微机时代：数据+操作
应用时代：数据结构+算法
OOP时代：对象+消息
再从技术发展来说，我们以2007 年1月9日iphone 1发布为界，此次进入智能机时代，2011年移动互联网兴起，2016大数据时代来临，基本5年一个时代，所以更新换代是非常的快。在这里，并不是要贩卖焦虑。只是随着技术发展，现在大数据、AI 、5G 已经很平常了，而我们大部分人还是一脸懵逼。至少我们需要知道这种现象，了解这个趋势。OOP 确实是软件开发的一大飞跃。但问题也来了，每个人对对象的抽象其实是很不一样的，梳理对象之间的关系，那更是丰富多彩。一个很明显的特点是，场景不一样，具体问题具体分析。
在这里，我要提的软件开发思想是：数据+服务。即：数据时代：数据+服务。
三、场景代入
系统说白了，无非记与计。记，简单说就是增删改查（CRUD），通过记录，实现数据化，条理化；再通过计算，按规则加工，形成自身或组织有用的信息，从而产生价值。
再来结合银行的应用场景，移动互联网时代，银行始终处于被动状况，迫切转型的意愿非常强烈。但银行是重资产，大业务，强流程，严监管，所谓船大难掉头，基本上后知后觉，亦步亦趋，不像互联网公司那样上新追快，大刀阔斧。金融行业是和资金打交道的，风险是时时刻刻存在。银行的业务规则特别多，计的层面繁杂，监管，风控，业务要求随时变化。
银行本质上而言，是由业务驱动的，所以业务部门一直是老大，科技是花钱的部门，花钱的往往吃力不讨好。有两个明显的门槛，一是业务与技术，二是组织管理。简单说，业务部门迫切需要开展的业务，需求整理通常不清楚，描述或者每个人对文字的理解有歧义，组织之间沟通协调也是很费劲的。技术部门需求分析、开发、测试、上线，整个项目工程阶段严格管控，一顿操作猛如虎，但是可能已经错过业务最佳时机了（最佳时机我们以最先占有市场为参考）。
另外在实践过程中，银行IT 系统会经常碰到下面几个情况：
1. 系统多显杂，一方面业务急，另一方面技术储备不足，大部分是外购。
2. 历史遗留问题：银行场景多，设计考虑不全，有的不规范
3. 参与人员水平参差不齐，流动大。
4. 强应用，没领导牵头，不好改，回归测试麻烦，风险没人承担。
通常管理人员比较在意的是：
1、代码质量
2、模块、功能重用
3、测试前移、测试驱动，减少错误率
4、生产问题定位、快速响应
严格来说，这些问题比较笼统，没有大而全的解决方法，没有成熟的解决方案，问题提出来，首先是解决的第一步，我现在愿意思考这些东西。 “数据+服务，集中制”是我的一个思路。
银行系统场景化后的技术逻辑大概有下面几种：
1.系统间交互，通常是报文通信处理
2.批量处理，定时或者异步
3.文件处理：上传、下载、解析
4.查询、分页
（欢迎补充…）
四、个人经验
使用每一个技术、框架、产品时，最好根据自己的情况制定规范。EOS 在做产品的过程中要考虑很多情况，但在企业中面临的问题就固定一些，例如不喜欢拖拽式开发业务逻辑可以不用，不要因为普元的培训时讲了这个方式就一定使用，也可以和普元的工程师探讨一下。使用一个框架的时候，技术团队可以多从设计原理、架构、面临问题的角度考虑一下框架的设计初衷，提高对技术的掌握。深入的掌握了 EOS，并和自己的实际结合了起来，变成了自己的框架，这一过程中对团队的技术积累也有了很大的提高。
在XX银行做外联前置，综合业务，一系列分行中间业务系统时，我改进了流程化的开发方式，变成统一逻辑处理的配置化。体现为两个思路：
1.解构--》Map数据池--》重构
2.向下（规则）扩展，向上（业务）兼容
具体说明如下：
1. 数据池化：处理规则，参考Linux设计思想：所有即文件，衍生：所有即报文，XML、JSON、定长、分隔符、数据库表（TABLE理解为对数据库的报文）、其他。再转化成：所有报文即MAP（承载所有数据，键值对）。实践证明，池化对大应用的性能提升是有立竿见影效果的，如连接池（通信、数据库）、缓存等。
2. 根据数据处理逻辑先后顺序，按以下步骤进行：
2.1 直接映射：
2.2 默认值：
2.2.1 直接默认值
2.2.2 有值的用原来的，没值用默认
2.3 转码：
2.3.1 规则转换
2.3.2 表达式求值
2.4 自定义：
通常也可以通过表达式配置实现
3、实现了上面的过程，通过对规则处理的扩展（无非IF-ELSE 的问题），实现业务逻辑的处理兼容。
规则分类：
3.1.计算规则：四则运算，判断等
3.2.数据处理规则：字符串处理，数据转换等
3.3.日期规则：日期格式转换，日期计算等
3.数据池化的好处是重用，也可以按规则增加数据，提高灵活性。
4.通过映射关系，将报文和数据池进行关联，然后封装一系列的服务，如报文解析，组装，通信处理等，完成业务信息传递。
通过这个方式，简化了开发过程，提高了代码复用率，基本上可以通过一个逻辑流实现整个业务的处理。通用的处理逻辑是：接收报文—>登记流水—>逻辑处理-->请求其他系统—>解析处理结果—>修改流水—>返回应答—>最后登记全部过程的报文（原始数据，查备）。
这个过程的特点并不是说不需要开发代码，经过两年多的实践（2017-7到2019-9），基本形成我们团队开发的参考框架，逐渐形成规范。代码只是跑逻辑，根据业务场景将逻辑框架搭起来（后续可以继续提炼，变成通用范式），信息全部移到数据库配置中，将焦点集中在配置管理上，后期维护只需要根据情况变化，进行对应调整。
在实践过程中，确确实实带来了好处，个人效率大幅度提升，将关注点放在规则扩展和集中配置上，快速应对业务变化，可以有更多时间关注其他事情。
不足之处：这套理念推广有受限，一是和EOS有脱节（可自行独立），二是太抽象，开发经验不够的理解不深刻（这个在团队梯队建设中是个争议点）。三是配置规则密集，没有直观有效工具，不清楚规则的，维护麻烦。（后续如果推广，肯定是要搭配配置工具的）
五、个人观点
银行IT 人员的核心竞争力不在于编码，而在于业务的理解和设计能力。科技+业务是趋势。
银行不是技术驱动型，而且由于历史原因，技术相对陈旧，但没关系，合适的才是最好的，熟练应用就足够。而且现在技术栈非常的广，工具链也是非常的长，而人的精力有限。在这个摸索过程中，需要做的是选用适合组织IT发展的技术栈，辅助工具，借助devops （个人认为devops思想是软件工程2.0）进行串联，系统化，管理过程信息化，原始数据真实，操作可追溯，统一“记”的规范，花重点在规则理解，场景化“计”（只有细而小，才能大而全），前端交互逐渐统一，提高用户体验，后端微服务，逐步形成XXX行的业务中台。