4.4.6 开发架构
4.4.6.1 开发架构定义
开发架构定义了软件开发环境中,软件模块的实际组织方式,具体涉及源程序文件、配置文件、源程序包、编译后的目标文件、第三方库文件等。
开发架构的设计着重考虑开发期质量属性,如可扩展性、可重用性、可移植性、易理解性和易测试性等。
为了避免开发人员不按照架构进行详细设计和编程,应该重视“开发架构视图”,让开发人员看到他们最关心的“程序单元“、”源代码目录结构“等内容,这些是不同程序团队开展具体工作的基础。如果程序员们不能从架构中看到上述内容,就会认为架构是一类“高来高去“的概念,就不会有积极态度。
从系统开发人员的角度来考虑问题,设计的架构要易于理解,易于开发,易于单元测试,最好做到让开发人员可以用最少的代码行数完成功能的开发。
开发架构设计要达到能支持并行的详细设计。
开发架构的设计主要完成下列工作:
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模块为例)![](https://i-blog.csdnimg.cn/blog_migrate/293d0e48bb43eddb57bd7a162595ac92.png)
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模块为例)
![](https://i-blog.csdnimg.cn/blog_migrate/9402b801d409283433b8789bfc6d047c.png)
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 代码组织结构
![](https://i-blog.csdnimg.cn/blog_migrate/fde58e57cbae89a6b24a6518d4176226.png)
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>
<groupId>${parent.groupId}</groupId>
<artifactId>${common-project-artifactId}</artifactId>
<version>${parent.version}</version>
</dependency>
2)其它公共服务模块
公共服务模块不依赖原子服务、流程服务;
2.原子服务模块
支持模块热部署方式;
原子服务模块不依赖任何其他模块,除bcap-scc-common-base外;
各原子服务模块不对外提供服务;
各原子服务模块之间不能互相调用;
每个原子服务要独立完成一个完整的功能;
3.流程服务模块
支持模块热部署方式;
流程服务模块依赖原子服务模块;
各流程服务模块通过Dubbo对外提供HTTP服务,采用JSON数据格式;
各流程服务模块通过Tesla平台提供的function-invoke调用原子服务模块提供的原子服务;
各流程服务模块之间不能互相调用;
4.4.6.4.3 目录结构
![](https://i-blog.csdnimg.cn/blog_migrate/bb94906db715246d00de41be1d711d6f.png)
项目整体结构采用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模块为例)![](https://i-blog.csdnimg.cn/blog_migrate/d9445f076891980f830bd5f25cfffd72.png)
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模块为例)![](https://i-blog.csdnimg.cn/blog_migrate/d06e9e31751c969959259ede36326956.png)
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模块为例)
![](https://i-blog.csdnimg.cn/blog_migrate/0147ee141a8181904abf5c4562dea4b2.png)
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 代码组织结构
![](https://i-blog.csdnimg.cn/blog_migrate/6a1fe6b067cec05c9780a10098e8bdf3.png)
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>
<groupId>${parent.groupId}</groupId>
<artifactId>${common-project-artifactId}</artifactId>
<version>${parent.version}</version>
</dependency>
4.4.6.5.3 目录结构
![](https://i-blog.csdnimg.cn/blog_migrate/04446e8884bb3e86c5d3109918c0761a.png)
项目整体结构采用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;
微信扫一扫,关注该公众号
该系列文章已经在微信公众号发布,如果感兴趣,请关注。
以后更多知识通过该微信公众号分享。
![](https://i-blog.csdnimg.cn/blog_migrate/a7db980c9f1b7905dd1c468c23f10eab.jpeg)