在如下这两篇篇文章我都或多或少强调过业务分层方面的的方法和注意事项，感兴趣的可以看看:
之前是说，现在是做。以我个人博客为例，我的博客最初只是一个单体应用，但是我决定将其拆分为多个模块，总体来说，还是一个单体war。但是性质是不一样的。
下面进入正题:
贴图说明:
blog-parent是父工程
blog-common主要放置工具类和其他可以复用的第三方插件或者是其他功能类
blog-entity 放置实体,通常是pojo也可以叫entity或者javabean
blog-dao 放置与数据库交互的接口类，也就是mapper
blog-service 业务接口及其实现类
blog-web 前台展示同时如果还开发安卓应用的话，直接提供接口
blog-generator 是代码生成器，主要应用于个人开发，提高效率用的
上述的依赖关系除了blog-generator之外，可以用思维导图可以表示为如下所示:
不过这个结构似乎也不太合理，适用于目前而言，业务不是特别大，最好采用这种形式表示:
两图比较主要区别在于将blog-common放到blog-service中，因为blog-service是业务逻辑，通常业务逻辑是可以复用多个的，而像一些判断或者是引用第三方插件，通常都在业务逻辑里具体实现后，而web模块中controlller直接调用即可，如果不放在blog-service中，就会出现一个问题，问题的主要凸显就是业务逻辑复用性差，导致很多都在controller里面下，也就是接口里面写，不利于复用，而且代码质量也会下降。
注意:
每个依赖记得都要maven install安装到本地仓库，否则会依赖不了，报错。
项目github地址为:https://github.com/youcong1996/ChallengerV.git
项目结果图如下所示:
前端模板主要采用的是layui，其实bootstrap也有很多这样的，大家可以在网上找找。
其实我参考了github上的不少项目还有一些小伙伴们的博客，其实还可以再细化分为如下(这里我还是用思维导图表示):
这样做的好处，主要是考虑可扩展性，前面列举的图一和图二可扩展性不是特别好，当然了，如果对于是一个人开发的话，直接单体应用即可，不用拆分，如果是两到三个人，可以按照图一和图二来。当然了，图一和图二还有一个考虑就是可读性，公司开发人员流动性比较强，特别是中小公司，总会有人走，也总会有人来，假如你是来的人，如果看到公司所有的代码全部在一个单体war上，而且有很多很多的com.xxxxx之类的，而且com.xxxxx下还有几十个类，试问你会作什么感想呢。
按照图三的设计，以后的扩展可以是这样：
随着业务一步一步扩大，可以将blog-web拆分为六个war,这就可能用到微服务架构了。
最后小结:
业务的扩展是一步一步慢慢来的，绝非一开始直接就业务拆分和分布式，那都是扯淡。