项目分层设计原则

「这是我参与11月更文挑战的第2天，活动详情查看：2021最后一次更文挑战」

我们来看一下后端项目，虽然我们的后端项目是一个单体，但是在前期我们也是可以把它进行一个拆分和聚合的。

首先看一个例子。假设现在我们有一个工厂，这个工厂是专门去生产汽车的。但是生产汽车的时候，在这个汽车在生产出来之前，会有很多的组装的构成。假设我们现在有很多的一些部件，比如有轮子、底盘、安全座椅、方向盘、车内音箱、蓄电池以及发动机，当然还有很多的一些组件。这些组件对于一个汽车厂商来讲，不太可能会在自己的工厂里面去生产这么多的一些组件。

它会把每一个部件外包给其他的公司去做的。在自己公司里面，可能只会生产一到两样，甚至是只有几个东西。随后在自己这里进行一个整合，比如进行一个组装。在我们生产之前先拆分，把我们所有的组件一个一个外包出去，让其他的一些外包商去进行开发。开发完毕之后，最终再进行一个聚合，一个整合，整合成一台汽车以后，它就是一个非常不错的产品，就可以把它流入市场去进行一些交易的销售。

在我们一开始前期先进行拆分，最后再进行一个聚合的一个目的，这样的一个好就是把每个组件进行了一个供用化。现在要生产三种不同的汽车，假设轮子其实都是一样的。只需要像同一个厂商去订购所有的轮子即可，就不需要额外的重复的再去生产轮子，拿过来直接去组装即可。

我们在开发项目的时候，和生产汽车实是差不多道理。在一开始我们要先把我们的一些业务模块等等先进行一个拆分，去进行一个分层，最终在我们去运行的时候去做一个聚合。这样子就可以降低我们的一个耦合度，也能够实现各个组件的一个公共化。

通过 Maven 去进行一个项目的聚合，就是把我们项目去进行拆，最终要去运行的一个包，它是一个 war 包或者说是一个 jar 包。它是通过很多的一些零碎的组件去进行聚合的。比如在我们的一个项目里面，可能会有 common.jar，它里面都是一些比较通用的一些方法、工具类、枚举，这些都会在 common 里面，那么它是单独的一个包，可以称之为它是一个子模块或者说是一个工程。

也可能会有 pojo.jar，这个就是一些和我们实体类相关的，比如 entity、bo、vo 和数据层交互，通过数据库表逆向生成的一些内容，一些实体代我们统称 pojo，也是一个包

也可能会有 mapper.jar 或者 dao.jar，就是数据层，在实际项目中，如果我们使用的是 MyBatis，就定义为mapper。如果使用的是 JPA 或者 Hibernate，一般就是定义为 dao.jar。

也可能是 service.jar，也就是业务层，它也可以独立成是一个 jar 包，是一个子工程一个子组件，也可能会 controller.jar，这个是接收我们的请求，去处理我们的请求。

除了以上介绍以外的组件，其实还有很多组件，都可以让使用 Maven 去进行拆分和聚合。

在我们的整个项目开发过程中，通过 Maven 的分层，可以使得我们项目层次会更加的清晰。当然在我们后端编程的时候，也会导致我们的数据层、业务层以及控制层会极度细化，这样子就可能会有三个不同的后端开发人员去进行开发和维护。

当然，在一些中小型初创公司，这三层一般是由同一个工程师去进行开发和维护的。多个不同的项目是可以通过 Maven 的依赖去实现代码的供用化，这样子就可以不必去重复的去造轮子的。

举个例子，现在可能我们有一个 A 项目，还有一个 B 项目，这两个项目在开发的时候，可能会有一些供用 jar 包，只需要去引入公共的依赖，就可以使得我们没有必要再重复的去编写额外的代码，这个就是一个组件的供用化。

如果你正在一个传统企业里面进行一些相应的项目开发的时候，可能会出现一种情况，就是同一份代码可能会出现在多个不同的项目里面。当这样的一份代码要去进行修改，你可能要去修改多个项目。这个就是没有去很好的使用 Maven 去进行项目的拆分和聚合。

如果一旦你使用这种分层的思想以后，相应的供应化的组件就可以相互的去进行依赖了。你只需要去修改一个地方，就可以同时被多个不同的项目去进行调用，这个就是分层和聚合的一个目的。

简单的小结一下，Maven 就是可以通过拆分项目为多个不同的子模块，可以按需让其他的项目去进行依赖，不同的子模块拒合在一起。那么最终就是一个可以运行的项目，并且它们可以使用不同的组件，相互不同的去进行依赖的。