4.4.6 开发架构java
4.4.6.1 开发架构定义程序员
开发架构定义了软件开发环境中,软件模块的实际组织方式,具体涉及源程序文件、配置文件、源程序包、编译后的目标文件、第三方库文件等。web
开发架构的设计着重考虑开发期质量属性,如可扩展性、可重用性、可移植性、易理解性和易测试性等。sql
为了不开发人员不按照架构进行详细设计和编程,应该重视“开发架构视图”,让开发人员看到他们最关心的“程序单元“、”源代码目录结构“等内容,这些是不一样程序团队开展具体工做的基础。若是程序员们不能从架构中看到上述内容,就会认为架构是一类“高来高去“的概念,就不会有积极态度。docker
从系统开发人员的角度来考虑问题,设计的架构要易于理解,易于开发,易于单元测试,最好作到让开发人员能够用最少的代码行数完成功能的开发。数据库
开发架构设计要达到能支持并行的详细设计。编程
开发架构的设计主要完成下列工做:后端
1.程序单元划分缓存
源文件、配置文件;微信
程序库、框架;
目标单元;
2.程序单元组织
项目划分;
项目目录结构;
编译依赖关系;
4.4.6.2 开发架构设计原则
4.4.6.2.1 模块内设计原则对于模块内的代码设计,遵循SOLID原则:
1.S:单一责任原则,若是你的代码中有一个类行数太长,可能你须要从新审视一下,是否是这个类承担了过多的责任。
2.O:开放关闭原则,对扩展开放,对修改关闭。因为对于代码的直接修改是很是危险的事情,由于你不知道这段代码原来被谁用了,所以不要贸然修改一段代码,而是选择用接口进行调用,用实现进行扩展的方式进行。
3.L:里氏替换原则,若是基于接口进行编程,则子类必定要可以扩展父类的功能,若是不能,说明不该该继承与这个接口。例如你的实现的时候,发现接口中有一个方法在你这里实在对应不到实现,不是接口设计的问题,就是你不该该继承这个接口,毫不能出现not implemented相似之类的实现方法。
4.I:接口隔离原则,接口不该该设计的大而全,一个接口暴露出全部的功能,从而使得客户端依赖了本身不须要的接口或者接口的方法。而是应该讲接口进行细分和提取,而不该该将太过灵活的参数和变量混杂在一个接口中。
5.D:依赖倒置原则,A模块依赖于B模块,B模块有了修改,反而要改A,就是依赖的过于紧密的问题。这就是常说的,你变了,我没变,为啥我要改。若是基于抽象的接口编程,将修改隐藏在后面,则可以实现依赖的解耦。
4.4.6.2.2 模块间设计原则
对于模块之间,则是采用云应用常说的十二原则,也称为云应用迁移原则。若是应用知足这12个要素,则能够比较顺利迁移到各类云平台。
1.基准代码
一份基准代码,多份部署。若是用镜像部署方式,则一个镜像能够部署到多个环境 (测试,预发,生产),而不是给每一个环境制做一个不一样镜像。
2.依赖
显式声明依赖。若是用镜像部署,则通常依赖被直接打在镜像中,或者声明在dockerfile中。
3.配置
在环境中存储配置。
4.后端服务
把后端服务 (例如缓存,数据库,MQ 等) 看成附加资源,相关配置和链接字符串经过环境变量注入,或者采用配置中心。
5.构建、发布和运行
严格分离构建和运行。若是使用镜像部署,则构建、发布、运行是经过镜像这种中间格式严格分离的。
6.进程
一个或者多个无状态的进程运行应用。容器运行时至关于进程,适用于无状态 Web/API。
7.端口绑定
经过端口绑定提供服务。容器也是经过端口绑定对外提供服务。
8.并发
经过进程模型进行扩展。容器运行时至关于进程,经过起多个容器能够任意扩展并发数量。
9.易处理
快速启动和优雅终止可最大化健壮性。docker 容器支持秒级启动和关闭。
10.开发环境和线上环境等价
尽量保持开发、测试、预发和线上环境相同。容器能够保证容器内运行时环境的一致性,还须要保证不一样环境的一致性,例如不一样环境内的操做系统,负载均衡,服务发现,后台服务,监控告警等要尽量一致。
11.日志
把日志看成数据流。
12.管理进程
后台管理任务看成一次性的进程。
4.4.6.3 开发架构实践-通用组件应用
4.4.6.3.1 代码组织结构
1.后台应用
按照模块分层进行组织,具体分为:
公共服务模块:bcap-common-base
总分通信模块:bcap-common-client
日终模块:bcap-common-dayend
风控模块:bcap-common-riskcontrol
自动任务调度模块:bcap-common-scheduler
其它公共模块:bcap-common-模块名称
系统管理模块:bcap-common-rbac;(开发环境使用,生产环境采用Tesla统一应用监控配置中心进行部署)
2.前台控制台
单独一个Web应用,调用后台应用提供的各类服务完成相关功能;
4.4.6.3.2 模块依赖关系
1.bcap-common-base
该模块为全局公共模块,其它各模块以项目依赖的方式直接引用,在类中直接import该模块下的类。
模块依赖设置:(模块下pom.xml)
<dependency>
<groupId>com.cmbc.bcap</groupId>
<artifactId>bcap-common-base</artifactId>
<version> ${bcap-common-version}</version>
</dependency>
2.其它公共模块以Jar包方式、服务方式提供服务。
4.4.6.3.3 目录结构项目总体结构采用Maven的多级模块结构,本项目采用2级结构,即使于模块的分类管理,同时避免级数太多带来的代码管理方面的问题。
1.一级目录:
bcap-common-parent
2.二级目录:
后台应用模块:bcap-common-app
公共服务模块:bcap-common-base
分行服务调用客户端模块:scc-common-client
日终模块:bcap-common-dayend
风控模块:bcap-common-riskcontrol
自动任务调度模块:bcap-common-scheduler
其它公共模块:bcap-common-模块名称
前台应用模块:bcap-common-web
4.4.6.3.3.1 公共服务模块目录:(以base模块为例)1.项目结构采用Maven默认推荐结构:
src/main/java存放应用Java代码;
src/main/resources存放应用配置文件;
src/test/java存放应用测试代码;
src/test/resources存放应用测试配置;
2.Java代码目录层次:
此模块为全局共用模块,主要存放全局的常量定义、工具类、全局过滤器等。
常量类(constant):存放本模块使用的常量定义;
工具类(util):存放本模块使用的工具类;
过滤器(filter):存放本模块使用的过滤器类;
其它:若是有特殊须要,可根据实际状况建立相关目录;
3.日志配置文件:
统一存放在src/main/resources文件夹下,名称为logback.xml。
此为全局性的日志配置文件,在模块中再也不单独须要日志配置文件。
4.log4j或logback日志文件:
建议预留一个磁盘空间比较大(至少50G)的磁盘专门用于存放日志文件。
5.模块配置文件:
统一存放在src/main/resources/META-INF/common文件夹下。
配置文件包括,但不限于下述文件:
datasource.xml
security-realm.xml
4.4.6.3.3.2 其它公共模块目录:(以dayend模块为例)
1.项目结构采用Maven默认推荐结构:
src/main/java存放应用Java代码;
src/main/resources存放应用配置文件;
src/test/java存放应用测试代码;
src/test/resources存放应用测试配置;
2.Java代码目录层次:
针对每一个模块,采用Tesla通用的三层结构,具体划分为:
1) 业务层(function):
业务处理,在此层进行数据库事务控制;
一个function对应一个业务功能,避免在一个function中定义多个业务功能;
对于业务功能较多(大于等于20个业务功能)的模块,建议创建子目录,对function进行分类管理;
对于同一个模块中功能能够进行分组管理;
2) 服务层(manager):
数据库组合操做,以便功能复用;
对于function须要调用的mapper中的原子操做,也必须在manager层进行封装,即直接透传,不能在function中直接调用mapper中的功能;
3) 数据访问层(mapper):
数据库原子操做,例如:单表的增删改查、多表的关联查询等;
其它目录:
实体域(domain):数据库表对应的Java Bean;
常量类(constant):存放本模块使用的常量定义;
工具类(util):存放本模块使用的工具类;
过滤器(filter):存放本模块使用的过滤器类;
其它:若是有特殊须要,可根据实际状况建立相关目录;
3.MessageSource配置文件:
统一存放在src/main/resources/META-INF/模块名/messages文件夹下。
例如:src/main/resources/META-INF/dayend/messages;
4.MyBatis配置文件:
统一存放在src/main/resources/META-INF/模块名/services/mapper文件夹下。
例如:src/main/resources/META-INF/dayend/services/mapper;
5.模块配置文件:
统一存放在src/main/resources/META-INF/模块名/services文件夹下。
例如:src/main/resources/META-INF/dayend/services;
基础配置文件包括,但不限于下述文件:
mybatis-config.xml
security.xml
cache-config.xml
6.初始化数据
统一存放在src/main/resources/initdata文件夹下。
4.4.6.4 开发架构实践-总行服务融合中心
4.4.6.4.1 代码组织结构
1. 后台应用
按照模块分层进行组织,具体分为:
1) 公共服务:bcap-scc-common
全局公共基础模块:bcap-scc-common-base
其它公共服务模块:bcap-scc-common-模块名称
2) 原子服务:bcap-scc-baseservice
产品模块:bcap-scc-baseservice-product
订单模块:bcap-scc-baseservice-order
其它原子服务模块:bcap-scc-baseservice-模块名称
3) 流程服务:bcap-scc-flowservice
支付模块:bcap-scc-flowservice-payment
信贷模块:bcap-scc-flowservice-credit
其它流程服务模块:bcap-scc-flowservice-模块名称
4) 系统管理模块:bcap-scc-rbac;(开发环境使用,生产环境采用Tesla统一应用监控配置中心进行部署)
2.前台控制台单
独一个Web应用,调用后台应用提供的各类服务完成相关功能。
4.4.6.4.2 模块依赖关系
1.公共服务模块:
1) bcap-scc-common-base
该模块为总行服务融合中心公共模块,其它各模块以项目依赖的方式直接引用,在类中直接import该模块下的类。
模块依赖设置:(模块下pom.xml)</dependency>
2)其它公共服务模块
公共服务模块不依赖原子服务、流程服务;
2.原子服务模块
支持模块热部署方式;
原子服务模块不依赖任何其余模块,除bcap-scc-common-base外;
各原子服务模块不对外提供服务;
各原子服务模块之间不能互相调用;
每一个原子服务要独立完成一个完整的功能;
3.流程服务模块
支持模块热部署方式;
流程服务模块依赖原子服务模块;
各流程服务模块经过Dubbo对外提供HTTP服务,采用JSON数据格式;
各流程服务模块经过Tesla平台提供的function-invoke调用原子服务模块提供的原子服务;
各流程服务模块之间不能互相调用;
4.4.6.4.3 目录结构
项目总体结构采用Maven的多级模块结构,本项目采用3级结构,即使于模块的分类管理,同时避免级数太多带来的代码管理方面的问题;
1.一级目录:
bcap-scc-parent
2.二级目录:
后台应用模块:bcap-scc-app
公共服务模块:bcap-scc-common
原子服务模块:bcap-scc-baseservice
流程服务模块:bcap-scc-flowservice
前台应用模块:bcap-scc-web
3.三级目录:
1) 公共服务目录bcap-scc-common:
公共模块:bcap-scc-common-base
其它公共服务模块:bcap-scc-common-模块名称
2) 原子服务:bcap-scc-baseservice
产品模块:bcap-scc-baseservice-product
订单模块:bcap-scc-baseservice-order
其它原子服务模块:bcap-scc-baseservice-模块名称
3) 流程服务:bcap-scc-flowservice
支付模块:bcap-scc-flowservice-payment
信贷模块:bcap-scc-flowservice-credit
其它流程服务模块:bcap-scc-flowservice-模块名称
4.4.6.4.3.1 公共服务模块目录:(以base模块为例)1.项目结构采用Maven默认推荐结构:
src/main/java存放应用Java代码;
src/main/resources存放应用配置文件;
src/test/java存放应用测试代码;
src/test/resources存放应用测试配置;
2.Java代码目录层次:
此模块为全局共用模块,主要存放全局的常量定义、工具类、全局过滤器等。
常量类(constant):存放本模块使用的常量定义;
工具类(util):存放本模块使用的工具类;
过滤器(filter):存放本模块使用的过滤器类;
其它:若是有特殊须要,可根据实际状况建立相关目录;
3.日志配置文件:
统一存放在src/main/resources文件夹下,名称为logback.xml。
此为全局性的日志配置文件,在模块中再也不单独须要日志配置文件。
4.log4j或logback日志文件:
建议预留一个磁盘空间比较大(至少50G)的磁盘专门用于存放日志文件。
5.模块配置文件:
统一存放在src/main/resources/META-INF/common文件夹下。
配置文件包括,但不限于下述文件:
datasource.xml
security-realm.xml
4.4.6.4.3.2 原子服务模块目录:(以pe模块为例)1.项目结构采用Maven默认推荐结构:
src/main/java存放应用Java代码;
src/main/resources存放应用配置文件;
src/test/java存放应用测试代码;
src/test/resources存放应用测试配置;
2.Java代码目录层次:
针对每一个模块,采用Tesla通用的三层结构,具体划分为:
1) 业务层(function):
业务处理,在此层进行数据库事务控制;
一个function对应一个业务功能,避免在一个function中定义多个业务功能;
对于业务功能较多(大于等于20个业务功能)的模块,建议创建子目录,对function进行分类管理;
对于同一个模块中功能能够进行分组管理;
2) 服务层(manager):
数据库组合操做,以便功能复用;
对于function须要调用的mapper中的原子操做,也必须在manager层进行封装,即直接透传,不能在function中直接调用mapper中的功能;
3) 数据访问层(mapper):
数据库原子操做,例如:单表的增删改查、多表的关联查询等;
其它目录:
实体域(domain):数据库表对应的Java Bean;
常量类(constant):存放本模块使用的常量定义;
工具类(util):存放本模块使用的工具类;
过滤器(filter):存放本模块使用的过滤器类;
其它:若是有特殊须要,可根据实际状况建立相关目录;
3.MessageSource配置文件:
统一存放在src/main/resources/META-INF/模块名/messages文件夹下。
例如:src/main/resources/META-INF/pe/messages;
4.MyBatis配置文件:
统一存放在src/main/resources/META-INF/模块名/services/mapper文件夹下。
例如:src/main/resources/META-INF/pe/services/mapper;
5.模块配置文件:
统一存放在src/main/resources/META-INF/模块名/services文件夹下。
例如:src/main/resources/META-INF/pe/services;
基础配置文件包括,但不限于下述文件:
mybatis-config.xml
security.xml
cache-config.xml
6.初始化数据
统一存放在src/main/resources/initdata文件夹下。
4.4.6.4.3.3 流程服务模块目录:(以payment模块为例)
1. 项目结构采用Maven默认推荐结构:
src/main/java存放应用Java代码;
src/main/resources存放应用配置文件;
src/test/java存放应用测试代码;
src/test/resources存放应用测试配置;
2.Java代码目录层次:
因为流程服务模块主要是根据需求对原子服务进行流程编排,因此在本模块只有function层,在function中进行服务流程的调用。1) 业务层(function):
业务流程调用;
一个function对应一个服务流程,避免在一个function中定义多个服务流程;
对于服务流程较多(大于等于20个服务流程)的模块,建议创建子目录,对function进行分类管理;
对于同一个模块中服务流程能够进行分组管理;
其它目录:
工具类(util):存放本模块使用的工具类;
其它:若是有特殊须要,可根据实际状况建立相关目录;
3.MessageSource配置文件:
统一存放在src/main/resources/META-INF/模块名/messages文件夹下。
例如:src/main/resources/META-INF/payment/messages;
4.模块配置文件:
统一存放在src/main/resources/META-INF/模块名/services文件夹下。
例如:src/main/resources/META-INF/payment/services;
基础配置文件包括,但不限于下述文件:
channel-config.xml
dubbo-config.xml
security.xml
security-client.xml
serviceflow-config.xml
5.服务编排流程文件
统一存放在src/main/resources/sflowDiagram文件夹下。
若是服务编排流程文件大于等于20个,能够参考function分类规则,在sflowDiagram目录下按照类别建立子目录进行分类管理。
6.初始化数据
统一存放在src/main/resources/initdata文件夹下。
4.4.6.5 开发架构实践-分行特点应用
以北京分行为例(bcap-bj)。
4.4.6.5.1 代码组织结构
1. 后台应用
按照模块分层进行组织,具体分为:
公共服务模块:bcap-bj-base
贷款模块:bcap-bj-loan
其它模块:bcap-bj-模块名称
系统管理模块:bcap-bj-rbac;(开发环境使用,生产环境采用Tesla统一应用监控配置中心进行部署)
2. 前台控制台
单独一个Web应用,调用后台应用提供的各类服务完成相关功能。
4.4.6.5.2 模块依赖关系
1.bcap-bj-base
该模块为公共模块,其它各模块以项目依赖的方式直接引用,在类中直接import该模块下的类。
模块依赖设置:(模块下pom.xml)</dependency>
4.4.6.5.3 目录结构
项目总体结构采用Maven的多级模块结构,本项目采用2级结构,即使于模块的分类管理,同时避免级数太多带来的代码管理方面的问题。
1. 一级目录:
bcap-bj-parent
2. 二级目录:
后台应用模块:bcap-bj-app
公共服务模块:bcap-bj-base
贷款模块:bcap-bj-loan
其它模块:bcap-bj-模块名称
前台应用模块:bcap-bj-web
4.4.6.5.3.1 公共服务模块目录:
参考《公共服务模块目录:(以base模块为例)》;
4.4.6.5.3.2 其它模块目录:
参考《原子服务模块目录:(以pe模块为例)》;
4.4.6.6 命名规则
1.项目名称:
1) 对先后台分开场景:以bcap-scc项目名称为例。
前台应用:bcap-scc-web;
后台应用:bcap-scc-app;
2)公共服务模块:
统一异常处理模块:bcap-scc-common-base;
其它公共服务模块:bcap-scc-common-模块名
3) 原子服务模块:
订单模块:bcap-scc-baseservice-order;
其它原子服务模块:bcap-scc-baseservice-模块名称
4) 流程服务模块:
支付模块:bcap-scc-flowservice-payment;
其它流程服务模块:bcap-scc-flowservice-模块名称
2.公共服务模块包名:(以base为例)
Function:com.cmbc.bcap.scc.common.base.function
Manager:com.cmbc.bcap.scc.common.base.manager
Mapper:com.cmbc.bcap.scc.common.base.mapper
domain:com.cmbc.bcap.scc.common.base.domain
util:com.cmbc.bcap.scc.common.base.util
constant:com.cmbc.bcap.scc.common.base.constant
filter:com.cmbc.bcap.scc.common.base.filter
3.原子服务模块包名:(以订单模块order为例)
Function:com.cmbc.bcap.scc.baseservice.order.function
Manager:com.cmbc.bcap.scc.baseservice.order.manager
Mapper:com.cmbc.bcap.scc.baseservice.order.mapper
domain:com.cmbc.bcap.scc.baseservice.order.domain
util:com.cmbc.bcap.scc.baseservice.order.util
constant:com.cmbc.bcap.scc.baseservice.order.constant
filter:com.cmbc.bcap.scc.baseservice.order.filter
4.流程服务模块包名:(以支付模块payment为例)
Function:com.cmbc.bcap.scc.flowservice.payment.function
util:com.cmbc.bcap.scc.flowservice.payment.util
5.Function实现类名称:
业务功能名称+Function.java
如业务功能为订单查询,则对应的function名称为OrderQueryFunction;
注意:Function必须采用注解方式开发;
6.Manager类名称:
服务名称+Manager.java
如服务为客户帐单服务,则对应的manager名称为ClientAccountManager.java;
7.Domain类名称:
实体名.java
如实体名为user,则对应的实体域名称为User.java;
8.Util类名称:
功能描述+Util.java
如日期格式转换工具类,则对应的工具类名称为DateFormatUtil.java;
9.常量类名称
常量类别+Constant.java
如错误码类型常量,则对应的常量类名称为ErrorCodeConstant.java;
10.MyBatis中Mapper名称:
1) Mapper接口类名称:
实体名+Mapper.java;
例如:UserMapper.java;
2) Mapper接口类的方法名称:
select、insert、update、delete方法分组定义,按顺序定义不能混乱;
方法名要能明确看出DB操做的含义,统一按照select+xxx+By+yyy或select+xxx+List+By+yyy或select+xxx+withRS、insert+xxx、update+xxx、delete+xxx+By+yyy。(xxx为实体名,yyy为条件描述,多重条件用简称描述);
接口类中方法要有功能说明,描述DB操做的功能;
3) Mapper配置文件名:
实体名+Mapper.xml,和接口类名称对应;
例如:UserMapper.xml;
4) Mapper配置XML文件中配置项名:
同接口定义,select、insert、update、delete分组并按顺序定义,且按照接口方法的顺序在XML中定义;
<select></select>、<insert></insert>、<update></update>、<delete></delete>的id名称与接口中方法名相同;
<sql></sql>共享列定义id名称遵循:定义列为表的部分字段时为simple+xxx+Columns、定义列为表的全部字段时为full+xxx+Columns、定义列为表与其余表关联时为xxx+join+yyy+Columns。(xxx为主实体名、yyy为关联实体名)
<resultMap></resultMap>返回结果映射定义id名称遵循:返回结果为表的部分字段时为simple+xxx+ResultMap、返回结果为表的全部字段时为full+xxx+ResultMap、返回结果为表与其余表关联时为xxx+join+yyy+ResultMap。(xxx为主实体名、yyy为关联实体名)
<sql></sql>和<resultMap></resultMap>定义在XML的最前面,后面再开始定义<select></select>、<insert></insert>、<update></update>、<delete></delete>;
5) MessageSource配置文件名:
实体名-message-source-zh_CN.properties
6) MessageSource文件中配置项Key名称:
function名称.消息码,统一小写;
例如:queryUserDetail.userid_not_exist;
微信扫一扫,关注该公众号
该系列文章已经在微信公众号发布,若是感兴趣,请关注。
之后更多知识经过该微信公众号分享。