银行管理系统的系统设计(详细指南)

4,130 阅读12分钟

在这篇文章中,我们将看看一个银行管理系统需要提供的主要功能,它的高层、低层设计,数据库设计,以及一些已经存在的银行管理系统。

目录:

  1. 银行管理系统
  2. 系统要求
  3. 高层次的设计
  4. 低级别的设计
  5. 数据库设计
  6. 领先的银行管理系统

银行管理系统

银行管理系统是一套基本工具和流程,使银行及其信贷机构能够履行其职能。银行管理系统的组成部分可能因银行而异,但一般来说,该系统包括管理基本交易的核心银行业务、贷款、抵押贷款以及通过ATM、移动银行和分支机构进行的支付。其他可能包括的组件有客户关系管理系统、风险管理系统、人力资源管理系统和商业智能系统。

系统要求

银行管理系统的要求提供了对系统行为的完整描述,并以业务预期为基础。系统的运作必须符合国家的法律和监管法案。例如,在美国,消费者金融保护局、联邦储备委员会、联邦存款保险公司和金融犯罪执法网络是管理银行活动的机构。

银行管理系统需要提供的关键要求可以分为功能和非功能要求。

功能性要求

功能需求描述了银行管理系统必须提供的服务,它们被细分为三个访问级别。管理员模式,柜员模式,和客户模式。

  • 客户:
    1. 用登录名和密码登录。
    2. 更新个人详细资料。
    3. 修改密码。
    4. 查看余额。
    5. 查看个人交易历史。
    6. 转账。
    7. 提款。
    8. 提交现金。
  • 出纳员:
    1. 使用登录名和密码登录。
    2. 更改密码。
    3. 注册新的银行客户。
    4. 查看客户信息。
    5. 管理客户账户。
  • 管理员:
    1. 用登录名和密码登录。
    2. 查看经理和客户的详细资料。
    3. 添加或更新银行分行信息。
    4. 添加或更新经理的详细资料。

该用例图提供了基本服务的概述:

非功能需求

非功能需求规定了可用于判断系统整体运行的标准,而不是具体行为。它们描述了像安全性、性能和可用性这样的突发属性,与可以绕过的功能需求不同,它们对于一个可用的系统来说是必须满足的。对产品是否满足非功能需求的评估通常简化为一个布尔答案:是或不是。

对于一个银行管理系统来说,最重要的非功能需求包括安全性、性能、可用性和可用性。

安全性
银行管理系统因受到恶意攻击而臭名昭著,所以安全是系统的主要要求。未经授权的数据访问是不被允许的。数据必须每天进行备份,并存储在安全的地方,与系统的不同设施保持一定距离。

在线交易和存储的数字文件必须按照128位或256位AES加密标准进行加密。该系统还必须采用防火墙软件作为对网络攻击的防御。

从客户端来看,系统必须在非活动期后提供自动注销,只接受有足够长度和非字母字符的安全密码,并在几次不成功的尝试后阻止登录尝试。

性能
银行管理系统是一个多客户系统,在同时调用时必须达到每个客户的响应时间目标,并且必须能够每秒无故障地运行目标交易数。该系统必须有效地利用硬件和能源资源,以尽量减少运营成本。

可用性
该系统必须为客户、出纳员和管理员提供不同的图形界面。所有的系统界面必须对用户友好,简单易学,包括帮助提示和信息以及直观的工作流程,特别是在客户界面中:客户必须能够快速学习和使用界面,而无需事先了解银行术语或规则。

界面必须自动适应不同屏幕尺寸的设备,并允许改变字体大小和颜色方案以提高可读性。

可用性
该系统必须在银行工作时间内可用。手机银行和自动取款机必须24小时可用,维护时间最少,每年可用时间达到99.999%。

软件要求

软件需求规范(SRS)是对将要开发的软件系统的描述,它是在功能和非功能需求之后,在分析的最新阶段提出的。可以应用于银行管理系统的一组编程工具和技术取决于是否使用内部、云或混合计算模式。

大多数大型金融机构的核心银行系统都是在内部运行的,这可能是由法律系统要求强制执行的,以方便在本国境内存储个人数据的服务器。

该系统的开发是基于以下技术:

  1. 运行Windows Server/Linux操作系统的服务器,运行Windows 10的ATM。
  2. 对于后端部分,需要像Java这样支持多线程的可扩展编程语言,数据分析和欺诈检测引擎需要使用Python。
  3. 现代前端框架,如React/AngularVue/jQuery用于用户界面。
  4. 具有支持ACID交易的引擎的关系型数据库管理系统,如Microsoft SQL Server或Oracle RDBMS。

高级别的设计

在对需求进行分析并达成一致后,下一个阶段是在高层次上描述系统架构。

单一的架构

实现银行管理系统的传统方式是采用单片机架构,用一个统一的单元来管理不同的任务。如下图所示,Java处理各种工作,这些工作来自分支机构,来自电子卡处理,来自对其他银行和客户开放的API请求。

负载平衡器在运行多份应用程序的应用服务器之间均匀地分配作业,在背面,应用程序管理数据库请求。负载平衡器还扮演着内部防火墙的角色,此外,外部防火墙提供了网络攻击的第一级保护。

该架构很简单,因此很容易开发和部署,通过负载均衡器进行扩展也比较容易--只需在需要时增加一个应用程序/数据库服务器。

单片式架构是最容易实现的,但从长远来看,它很难维护,而且很难增加新的功能或更新旧的功能。此外,在单体架构下,很难在开发堆栈中引入新的工具和框架,因为单体结构内部没有连接新技术的点。

事件驱动架构

事件驱动架构是传统单片机架构的替代方案之一,它以 "事件 "而非实体为中心。例如,当办公室出纳员提交一个新客户时,当客户按下ATM按钮取钱时,或当账户余额越来越低于阈值时,都会发生事件。所有传入的事件都在API层内注册,并添加到Kafka流中。

Apache Kafka是一个开源的分布式事件流平台,在消费者之间分配事件。应用工作、数据存储、统计收集器、通知程序和特殊的Fraud Check引擎。Fraud Check是用Python编写的,用于自动检测和阻止可疑的交易,以防止洗钱和其他违法行为。

有了事件驱动的架构,实现新的服务就更容易了,因为不需要在它们之间不断地同步状态,例如,将当前的余额状态与即将到来的来自信用卡和开放API的交易同步。相反,程序可以引入一个控制和修复余额变化的偶数,所以交易服务只需要关于余额变化的信息,而不关心其他交易和进程。

由于事件驱动架构需要在初始阶段进行仔细的设计,因此需要在开发上花费更多的时间和资源,对于那些以大型客户审计为目标并提供一系列不同服务的大型金融机构来说,这是一个不错的选择。

低层次的设计

根据数据访问对象模式(DAO),银行管理系统应用程序在一个银行接口中定义了所有可用的操作。这个接口的实际实现是可以互换的,不需要在前端进行修改。

public interface Bank {
	
	// Create
	boolean add(Customer customer);
	boolean add(Employee employee);
	boolean add(Account account);
	boolean add(Loan loan);
	boolean add(Branch branch);
	
	boolean add(Transaction transaction);
	
	// Read
    List<Customer>findAllCustomers();    
    Customer findCustomer(String param);
    
    List<Employee>findAllEmployees();    
    Employee findEmployee(String param);
    
    List<Account>findAccountsOfCustomer();    
    List<Loan>findLoansOfCustomer();
    
    List<Transaction> findTransactionsOfAccount();
    List<Transaction> findTransactionsOfCustomer();
    String getTransactionDetails();
	
	// Update
	boolean update(Customer customer);
	boolean update(Employee employee);
	boolean update(Account account);
	boolean update(Loan loan);
	boolean update(Branch branch);
	
	// Delete
	boolean delete(Customer customer);
	boolean delete(Employee employee);
	boolean delete(Account account);
	boolean delete(Loan loan);
	boolean delete(Branch branch);
}

public class BankImp implements Bank{
// Implementation of Bank methods
}

该应用程序有六个持久性实体,与数据库表相对应。账户、分行、客户、雇员、贷款和交易。抽象类Person重用了Customer和Employee类的重复代码,并不存在于数据库中。

@Getter
@Setter
public abstract class Person {
	
	private int id;
	
	private String login;
	private int passhash;
	
	private String name;
	private String phone;
	private String email;
	
	private Date registrationDate;
}

@Getter
@Setter
public class Customer extends Person{
	
	private Set<Account> accounts;
	
	private Set<Loan> loans;
}

@Getter
@Setter
public class Employee extends Person{
	
	private String position;
	
	private Employee manager;
	
	private Branch branch;
}

@Getter
@Setter
public class Account {
	
	private int id;
	
	private Customer customer;
	
	private Branch branch;
	
	private Date openingDate;
	
	private BigDecimal currentBalance;
	
	private BigDecimal interestRate;
	
}

@Getter
@Setter
public class Loan {

	private int id;
	
	private Customer customer;
	
	private Branch branch;
	
	private Date startingDate;
	
	private Date dueDate;
	
	private BigDecimal amount;
	
}

@Getter
@Setter
public class Transaction {
	
	private int id;
	private Date date;
	
	private BigDecimal amount;
	
	private Account account;
	
	private Employee teller;	

}

@Getter
@Setter
public class Branch {
	
	private String id;
	
	private String address;
	
	private String phone;
}

对持久化实体的操作是通过控制器类控制的,每个持久化实体有一个控制器。这些控制器将在银行接口的实现中被调用。

public class CustomerController {
	
	public Customer createCustomer();
	
	public boolean removeCustomer(){};
	
	public Customer getCustomerOfAccount(Account account){};
	
	public Customer findCustomerByID(int id) {};
	
	public List<Customer> findCustomersByName(String name) {};	
}

public class EmployeeController {
	
	public Employee createEmployee(){};
	
	public boolean updateEmployee(){};
	
	public boolean removeEmployee(){};
	
	public boolean setManager(){};

}

public class AccountController {
	
	public Account createAccount(){};
	
	public boolean updateAccount(){};
	
	public boolean removeAccount(){};
	
	public List<Accounts> getAccountsOfCustomer();
	
	public String getAccountDetails();
}

public class LoanController {

	public Loan createLoan(){};
	
	public boolean updateLoan(){};
	
	public boolean removeLoan(){};
	
	public List<Loan> getLoansOfCustomer();
	
	public String getLoanDetails();
	
}

public class TransactionController {

	public List<Transaction> getTransactionsOfAccount(Account account){};
	
	public String getTransactionDetails(Transaction transaction);	

	@Transactional
	public boolean withdraw(Account account, BigDecimal amount)  {}
	
	@Transactional
	public boolean deposit(Account account, BigDecimal amount) {}

	@Transactional
	public boolean transfer(Account from, Account to, BigDecimal amount)  {}
}

public class BranchController {
	public Branch createBranch(){};
	
	public boolean updateBranch(){};
	
	public boolean removeBranch(){};
	
	public String getBranchDetails(){};
	
	public List<Employee> getBranchEmployees(){};
	
}

需要注意的最重要的类是带有with withdraw(), deposit()和transfer()方法的TransactionController,所有这些方法都必须提供绝对的准确性,因为银行和客户都不愿意损失钱。这样的方法应该作为一个单一的工作单位(数据库事务)来管理,具有回滚所有变化的能力,并包括对发送和接收账户的多重检查,对欺诈的检查,以及在提交交易前的其他检查。

数据库设计

业务管理系统使用基于SQL的数据库,如Microsoft SQL Server或Oracle RDBMS,包括主要业务实体的表和它们之间的链接表。
1-3

客户关系存储银行客户的信息,每个客户可以有多个余额账户贷款

分行关系存储银行分行的信息,银行雇员被分配到其中一个银行分行。客户账户和贷款也被分配到其中一个银行分行以方便管理。每个雇员可以有另一个雇员被指定为经理。

当客户通过信用卡、手机银行或在银行分行办公室取款、提交或转账时,有关该行动的信息被存储在交易表中。并非所有的交易都被接受,因为银行要进行多重检查,失败的交易历史被存储在FailedTransactionsLog表中,以收集数据,为银行安全系统的改进提供依据。

数据库中有一些表没有反映在领域模型中。贷款类型账户类型交易类型,因为它们代表静态信息。

领先的银行管理系统

传统上,大型银行更喜欢自己的银行管理系统部署在内部,传统方法的替代品是基于云的银行解决方案或适应开源软件项目。银行管理系统的选择并不是一件简单的事情,因为市场上有很多基于云的解决方案,具有不同的功能和定价计划。

例如,Finacle提供核心银行解决方案和云原生银行套件作为SaaS,"以强大的基础吸引客户"。Finacle可以在AWS或MS Azure上运行,应用组件化的基于微服务的架构,与技术平台无关。

Cobis是另一个云原生、实时、模块化的金融产品发起系统,提供可定制的工作环境、全渠道门户(移动、互联网、呼叫中心、分行、代理、ATM、API)、风险和合规模块以及分析。它还支持与第三方的整合,以实现交叉销售和信息共享,并提供SaaS和内部部署两种方式。

具有开放代码的平台的一个例子是Apache Fineract或建立在它之上的Mifos X社区应用程序,它有170多个贡献者和超过390万个Docker拉动。Fineract的目标是创新的移动和基于云的解决方案,并为所有人实现数字交易账户。Fineract的领域包括由客户持有的账户,以及对这些账户进行的交易。其他功能支持柜员操作、基本财务管理、会计、投资组合管理、认证、开户以及零售银行业务中常见的类似主题的用例。

MyBanco是一个完全免费的核心银行平台,它是在GNU Affero通用公共许可证下的PHP编写的,允许对代码进行任何修改以适应业务的需要。

通过OpenGenus的这篇文章,你一定对银行管理系统的系统设计有了深刻的认识。