基于分布式、服务化的maven项目文件规划

引言

此文不是纯粹介绍maven概念，而是介绍一个具体的maven项目文件规划

这个规划可能适合于研发比较复杂的业务，这些业务有分布式和服务化的需要。

这个规划能够解决因为分布式和服务化要求而引起的项目繁多，项目混乱的问题。

与此同时这个规划也可以解决了在项目研发中出现的重复“轮子”的问题。这些“轮子”主要来源于两类：

1. 代码的重复“轮子”，所以要抽取项目，导致项目数量进一步增多。
2. 人工构建项目的重复“轮子”，构建的关系越来越复杂，错误率也越来越高，所以要通过基于配置和约定的方法来实现自动化构建。

其他的不多赘述，直接上干货。

实际的规划图

所有parent的公用职责

1. 构建它下面聚合的所有项目。约定是只聚合它子目录的项目，不能跨目录去聚合
2. 管理它聚合的项目的通用特性，即存在继承关系。这些通用特性，是从它聚合的项目本身抽取的职责而来。约定这个继承和聚合使用同一个项目。
3. 统一管理它聚合的项目中使用依赖其他项目或者jar的版本。聚合的项目只允许依赖它下层的项目。具体分层，看下文的分层依赖关系

we-parent的职责

　　职责：一键构建所有需要发布的项目。

　　通用特性：

1. 所有项目初始时就带有这些jar包的依赖，例如：testng(单元测试相关),h2(单元测试相关),easymock(单元测试相关),lombok（根据注释自动生成setter和getter）
2. 所有项目的额外特性，例如：单元测试插件
3. 项目发布管理，例如：私一的maven私服配置

we-core-parent的职责

　　职责：它所聚合的的项目与业务没有关联的，只提供基础能力。简称：core项目。例如：数据库持久能力，redis缓存能力,http封装能力，通用工具能力等。

　　通用特性：

• Javadoc插件，用于生成javadoc

we-base-parent的职责

　　职责：它所聚合的的项目有且只能代表一个真实存在而且能独立存在的核心实体对应的业务，简称：base项目。

　　概念解释：

• 真实存在：即可以用一个具体的客观物体承载的。比如：用户，课程，试题
• 独立存在：不依赖于其他的任何业务，放在哪里都可以独自呈现。比如：试题放在哪里都可以显示，课程放在任何地方也可以呈现。
• 核心实体：一个业务服务其实通过一个实体就可以来实现了，顶多是字段属性多一些、实现复杂一些。为了更好的实现，我们可以会把这个实体拆分成很多。但是不管拆分多少个实体，总会有一个是最为重要的，其他的实体如果没有这个实体就没有任何意义。比如试题抽象成试题实体和答案实体。如果没有试题的存在，答案是没有存在的意义的。所以试题就是核心实体。

　　通用特性：暂无

we-business-parent的职责

　　职责：它所聚合的的项目必须是一个提供“共享”业务流程，简称：business项目。在这个流程过程中有可能需要引用base服务。它本身没有一个真实存在而且能独立存在的核心实体

　　概念解释：

　　共享：在产品规划上，该服务可能会被多个产品使用，即为共享。

　　通用特性：

• 统一引用数据库持久能力，即数据库实现项目。

we-web-parent的职责

　　职责：它所聚合的的项目可以通过互联网向用户提供服务，在产品规划上它自己独有的不被共享的业务，简称：web项目。

　　通用特性：

• 统一引用http解析能力。对http的解析及渲染。
• 监控相关

分层依赖关系

除了we-parent，每一个parent对应的职责就是一个项目分层。这些项目分层的从上到下的关系如下图。

如何使用

　　假设：现在来一个产品稿（prd，原型或者定稿需求）

　　使用步骤如下：

1. 分析一下，这个产品是否要对用户独立提供服务，不受其他的产品影响。如果要，则新建web项目。
2. 分析一下，这个产品有没有哪些业务是准备被其他产品使用的，即在其他产品的界面有没有体现本产品。
3. 如果有，分析一下这些公用的业务，有没有包含一个流程性，即它的业务在组合其他已有base项目。如果有，新建一个business项目
4. 分析一下，这个产品有没有可以独立存在，不依赖于任何其他服务的业务。如果有，新建一个base项目。
5. 当实现这些编码时，如果有遇到一些与业务无关的，只提供能力的，则新建一个core项目。

　　总结来说：就是分析的时候根据分层，从上到下。把每一层的职责分析一下，如果有则新建一个。每一个项目，都必须建在对应的parent之下。