我理解的银行核心业务系统软件架构 - 第3页 - 金融行业 - ITPUB论坛－专业的IT技术社区

wangjia

并非这样，基于对基本业务应用的建模，能够衍生出非常复杂的业务模型。例如额度、承诺类业务都可以看成是账户的一个特殊形式，最大程度的实现功能复用，存款和贷款都是账户的一种的体现形式。银团贷款、证券化业务也可以基于这一模型予以构建等等。
用模型化的思想抽象的来看待需求，而非直接对用户需求予以实现，这应当是现代核心系统最大的特点。
本帖最后由 fupingyu 于 2012-4-10 00:47 编辑
家住海淀 发表于 2012-4-6 22:51

交易组合在那里? 对外围要求太高似乎，持久层也看不出究竟做什么? 交易完整性如何控制
持久层这里指的就是数据库管理系统，要求其配置要支持全局事务，全局事务控制在服务层；如果系统涉及多个后台服务（如TUX SERV、CICS SERV等），也希望这些合作的后台服务是支持全局事务的，如不能则要针对它做出错处理。交易组合体现在上层服务或逻辑组件对下层服务或逻辑组件的组合调用。
业务梳理是个细致艰巨的工作，现在的做法是由内而外，功能和数据合理分拆，尽量做到高内聚松耦合。
fupingyu 发表于 2012-4-10 00:57

业务梳理是个细致艰巨的工作，现在的做法是由内而外，功能和数据合理分拆，尽量做到高内聚松耦合。
建议多参考一些成熟的国际产品，分析其软件架构的优势和劣势，站在巨人的肩膀上可以少走很多弯路。
还是要首先考虑核心产品自身的架构。集成架构上需要考虑，但这不是产品的首要因素。如何让自己变得更易于修改，更富有弹性，更好的抽象外部世界才是保证集成的手段。
此外，这幅图应该只是应用的部署图。揭示软件的架构更重要的是软件内部的模块结构图（设计时）、使用关系图（运行时）。良好的软件架构设计是保证产品成功的关键。
本帖最后由 eliasyue 于 2012-4-11 13:01 编辑
fupingyu 发表于 2012-4-10 00:44

持久层这里指的就是数据库管理系统，要求其配置要支持全局事务，全局事务控制在服务层；如果系统涉及多个 ...
虽然成功的核心实施项目离不开跨平台、跨系统的组合服务，但跨平台的组合服务并非核心产品的职责所在。
核心的软件架构，需要做的是抽象核心业务的世界，抽象客户、账户、业务事件、金融条件、合约等等的模型对象，以及这些对象之间如何进行通信、协作。
在系统内组合各个对象的操作是必要的，但不存在跨平台的事务控制问题。同一平台内的事务控制能够通过应用平台层面的事务控制机制即可处理，无需在这方面花费太多精力。
eliasyue 发表于 2012-4-11 12:53

建议多参考一些成熟的国际产品，分析其软件架构的优势和劣势，站在巨人的肩膀上可以少走很多弯路。
还是 ...
你的建议很好！很值得我借鉴！