前言

在我这么多年的开发生涯中，要说最宝贵的东西，那就是已经踩过的坑已经开发过的功能和已经总结出来的经验了。但是，也是在这几年的开发生涯中我愈发觉得我需要一个可以随时可用的工具箱了，尤其是每到一个新项目或者新公司就需要解决大量的之前已经解决过的问题的时候。

每个新项目或许都会需要解决跨域问题，需要重复开发用户与权限之类的通用模块，如果是分布式系统可能还需要开发或者部署重复的ID生成器服务。我期望我的项目能够快速开始，而不是浪费在这些重复且无聊的工作上面。

是的，本文的初衷便是为了解决这些问题，希望将大量的可复用的内容沉淀下来，最终每个新项目都可以在旧项目的基础之上快速开发上线，旧项目的经验可以被新项目所吸收，可以避免大量的重复劳动。这是由一个大项目族组成的大项目，我将在开发Coin4U项目过程中逐渐明晰与完善这个项目族。

后端项目族

后端项目族从不同层面的需要构建起整个项目族，整个项目本质上是一个类树的结构，项目与模块之间有着明晰与严格的层次与依赖关系。

整个项目族都是使用jdk17版本开发的

lee-parent

lee-parent是所有项目的基础，这是一个类似于spring-boot-dependencies的项目，但是其实十分轻量的项目，主要职责是管理三方依赖，解决依赖冲突。我们开发的所有项目都是基于这个parent来开发的。

也就是说我们的子项目可以通过两种方式来引入

<parent>  
    <groupId>com.bigbrotherlee</groupId>  
    <artifactId>lee-parent</artifactId>  
    <version>0.0.1-SNAPSHOT</version>  
</parent>

或者

<dependencyManagement>
    <dependency>  
      <groupId>com.bigbrotherlee</groupId>  
      <artifactId>lee-parent</artifactId>  
      <version>${lee-parent.version}</version>  
      <type>pom</type>  
      <scope>import</scope>  
    </dependency>
</dependencyManagement>

总的来说他又以下三个目标：

  1. 管理依赖
  2. 提供工具、封装与增强，减少重复开发
  3. 在本地、单体应用和微服务应用维度三个维度提供增强

所以该项目目前有以下几个子模块，并且他们有着简单且单向的依赖关系：

se -> ee -> cloud
-> 表示被依赖关系

lee-parent-se

在一些公司内部通常会有一个xxx-lang的jdk原生功能增强项目。se是一个类似的子模块，但是其功能要比java增强要复杂一些。包括诸如ID生成器，日期转换器、压缩、位运算等等实用功能。还包括验证码生成等等一些可能常规上不太会放在lang上的功能。

我个人觉得se作为一个单独模块还是太重了，需要在后续项目慢慢发展之后逐步拆解开来。

lee-parent-ee

ee是对第三方框架的增强，比如spring、tkmapper、jpa、mybatis等等。将诸多框架的增强杂糅在一起是一个不好的的实践，也是需要在后续逐步将对不同框架的增强拆解成不同的单独的模块。

lee-parent-cloud

cloud是对分布式功能的增强，比如loadbanlancer策略等等。和ee一样，坏味道实践需要逐步拆解开来。

biz-framework

biz-framework是在parent基础之上开发的一套业务框架，目的是帮助业务开发快速集成业务。

我们常常会遇到这样的情况，公司新开了一个项目，需要重新对接支付，对接第三登录，对接通知等等功能，如果公司内部已经有了可用的服务的情况下还好说，调用现成的统一服务就行了，如果在一些极端情况下，比如相应的功能没有服务化或者干脆新项目是挂在需要并行的另外的主体公司下面的情况下，我们可能需要重新对接第三方接口。

biz-framework就是为了解决类似的问题而创建的项目。
需要注意的是，biz-framework是一个独立的项目，也就是说parent无法管理biz-framework的版本，其依赖冲突也是需要由biz-framework自行解决的，也就是说，我们使用biz-framework的时候需要这样使用：

<dependencyManagement>
    <dependency>  
      <groupId>com.bigbrotherlee</groupId>  
      <artifactId>biz-framework</artifactId>  
      <version>${biz-framework.version}</version>  
      <type>pom</type>  
      <scope>import</scope>  
    </dependency>
</dependencyManagement>

这样才可以解决依赖项目依赖问题。

目前项目有以下几个子模块组成：

notice-work

对接所有的第三方通知，比如电子邮件、短信、电话、微信、钉钉和飞书等等。提供一个可编程的快捷对接接口，当我们需要使用对应功能的时候只需要对接注入少许配置，就可以快速获得对应的通知功能。

oauth-work

对接所有的第三方登录授权服务，比如QQ、微信、企业微信、钉钉、飞书、抖音等等。提供一个可编程的快捷对接接口，业务方只需要注入少许的配置，就可以快速对接。

pay-work

对接各种渠道支付。比如：微信、支付宝、威富通、汇付、云闪付、银联、paypal、btc等等。提供一个可编程的快捷对接接口，业务上只需要注入少许配置就可以实现完善的支付功能。

biz-common

基于biz-framework开发的业务系统上常用的业务组件与模块。相较于framework，common提供了一个个业务模块完善的功能，比如用户模块、权限与授权。
也就是说biz-common本身就是一个完善可用的模块，它就像是一更加轻量的若依系统，提供了一系列完善的可插拔的业务模块供业务方直接集成使用，这使得业务方可以不用开发一些重复的边缘模块，更加集中在业务上面。

同样的，使用需要像如下引入，以解决依赖问题

<dependencyManagement>
    <dependency>  
      <groupId>com.bigbrotherlee</groupId>  
      <artifactId>biz-common</artifactId>  
      <version>${biz-common.version}</version>  
      <type>pom</type>  
      <scope>import</scope>  
    </dependency>
</dependencyManagement>

但是使用上会更加复杂，因为完善的功能模块通常需要依赖第三方服务比如数据库。

user-common

配置好相应的配置之后就可以直接使用服务了。提供常规的用户与权限功能。

common-server

common-server是基于parent开发的一系列通用服务，一些通用的微服务功能是不需要每次都重新开发的，比如ID生成，短网址，授时等等。与上面的项目不同，common-server是一个通用的服务，而不是一个pom父项目。

提供了一个部署即可用的服务，可以通过开关配置调整服务的可用功能。

ID服务

为其他服务提供统一的ID生成服务。一次性生成1到n个ID返回到其他服务。部署即可用，可以提供配置关闭。

Time授时服务

为其他服务通过统一的时间。在分布式系统中服务时间的统一是至关重要的。部署即可用，可以提供配置关闭。

短网址服务

生成和解析短网址。部署即可用，可以提供配置关闭。

结语

我希望提供各个层面的封装来尽可能减少开发量，同时业务方又可以选择不同层面的模块来定制自己的业务。那么整个cornerstone项目就具有极大的弹性，与极大的可复用性，使之真正成为项目基石，所有的项目基于该项目开发生长，又由于业务的增长会带来新的技术与新的业务，当这些新的业务与技术沉淀到cornerstone的各个层面之后，良性循环就开始了，cornerstone会越来越厚实，新业务的开发将逐渐变成从已有的工具箱中取出相应的工具来完成业务方想要实现的业务。

标签: none

添加新评论