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模块为例）
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>
<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 目录结构
项目整体结构采用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>
<groupId>${parent.groupId}</groupId>
<artifactId>${common-project-artifactId}</artifactId>
<version>${parent.version}</version>
</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；
微信扫一扫，关注该公众号
该系列文章已经在微信公众号发布，如果感兴趣，请关注。
以后更多知识通过该微信公众号分享。
