微服务项目到底如何分模块？

　　企业级项目结构封装释义
　　如果你刚毕业，作为Java新手程序员进入一家企业，拿到代码之后，你有什么感觉呢？如果你没有听过 多模块、分布式 这类的概念，那么多半会傻眼。为什么一个项目会有这么多个子项目？这个项目里为何没有版本，这个parent是指向啥？
　　今天我们模拟真实企业场景，来让大家掌握一些项目架构方面的知识。
　　前提假设
　　我们是同一家公司woniu科技，这家公司有5个开发小组，其中3个小组负责开发运营电影票务网站，另外2个小组开发运营外卖网站。
　　思考
　　那么从技术管理的角度，几个项目组之间需要有哪些层面上的相同呢？
　　一般而言，公司内部会考虑统一技术栈和框架的版本，也会提供统一的工具类。
　　好处显而易见：
　　方便进行管理，比如，统一升级版本，统一加入某项功能等等。
　　降低学习研究的成本，企业级开发框架种类繁多，版本众多，统一之后程序员要学习的技术是最小的，相关技术专家也可以深入的研究某项技术彻底hold住。
　　减少出问题的概率以及排错的成本，一旦出错所有人都可以加入解决问题。
　　统一的技术框架之间是兼容的，方便项目之间的互相操作、互相调用，共享代码等等。
　　降低人员调动、招聘及培训成本。
　　…
　　所以，一个公司会尽力统一能够统一的一切，除非特殊的业务或者技术的需求。
　　统一规范
　　技术选型
　　一般而言，技术选型是一早确定的。比如选用SpringBoot还是Play框架，选用单体还是分布式，选用MySQL还是Oracle。选型结束之后变动的成本巨大，一般不会大改。开发团队在需要使用某项技术之前，应当先向技术负责人确定是否有已经定好的框架，避免不同团队之前使用不同的技术。
　　统一版本
　　技术框架选定之后，还需要统一版本。这个怎么做呢？
　　一个流行的解决方案是通过全公司共享一个总父项目，各个子项目不加版本，由这个总父项目来控制版本，子项目会根据情况自动升级。
　　这种专门管理版本的项目，我们一般称为BOM(Bill Of Materials 物料清单)。已经成为非常成熟的模式。如果你沿着spring-boot的parent往上追溯也会找到spring-boot-dependencies，就是一个BOM。
　　这里需要了解下    这个标签，它会管理依赖的版本，包括依赖排除这些，但是不会为子项目加入这个依赖。这点跟    是不同的，这也是BOM的关键技术。
　　另外，子项目通过    指定父项目。
　　比如woniu科技会创建一个woniu-parent项目，负责管理版本全局统一的父pom。
　　统一工具类
　　一般公司内部都有自己的工具类，会提供一些类似如日期格式化，ID生成等等的工具类。这类的工具类是非常通用的，每个项目的每个模块都会需要用上。所以会考虑直接在总父pom中加入依赖。一旦加入就是全局引入，所有项目就自动获得这个依赖。所以除了这个统一工具类的依赖以外，很少会再加入其他依赖。
　　比如woniu科技会创建一个woniu-commons项目（单纯的maven-quickstart项目）来统一提供工具类，具体功能如下：
　　提 供各种基础工具
　　统一响应格式（统一结果，但是通过拦截器封装结果）
　　统一错误码
　　统一的异常父类
　　统一的ID生成工具
　　…
　　统一项目结构
　　项目当然可以是单体项目。但是既然是为了解决可能面对的复杂问题，我们就来模拟一个复杂的项目结构。
　　这里涉及到maven多模块项目的概念。
　　maven多模块项目其实是指在一个项目中包含多个独立的模块项目，每个模块可以单独打包成jar或者war。如下图所示。
　　最外层是一个总的项目（称为总控pom），这个项目只有一个pom而没有src等，仅用来管理依赖，并联系起所有的模块。
　　模块项目指的是在项目目录下的项目。可以是任何项目。
　　总控pom与子模块怎么确认呢？
　　总控pom里通过和确认子模块 子模块通过确定总控pom
　　模块与模块之间通过来建立起联系。
　　如下图示意，蓝色方框表示总控pom，浅蓝色方框表示模块：
　　理论上，模块可以有任意多个，也可以是任何名称。这个问题跟技术无关，理论上你可以叫dog,cat,miaomiaomiao，但是显然不够专业和实用。这就是公司内部要确定的规范了。
　　那么具体有哪些模块呢？
　　这里举例如下，woniu科技确定的统一的项目结构及解释如下：
　　common 项目工具模块
　　facade 给外部用的AP接口，打包后发布给其他服务调用方作为接口来使用
　　service 服务
　　dao 数据库访问层
　　model 数据模型层
　　domain 领域层，用来聚合复杂的领域模型
　　integration 集成层，集成外部的服务，例如云服务
　　web 提供web服务，目前这层基本没有了
　　assembly 打包层，将所有内容打包
　　下图展示了最少模块数量的一个多模块项目，除了common和facade以外的内容都放在assembly中
　　统一配置
　　多个开发组之间可能会共用一些资源，比如用同一个redis集群，mq集群。那么这些配置是一致的，能够不重复配置是最理想的。万一redis集群地址更改也不需要每个项目改动。
　　还有一个可能是存在通用配置，比如日期格式在全公司是统一的，日志配置都是统一的，actuator暴露的端点也是一致的。
　　这类配置管理需求在spring-boot出现之前是非常难实现的。spring-boot的特性之一是外化配置，加上nacos的配置管理客户端，将配置完全交给nacos来管理。
　　nacos支持共享配置，那么就可以将一个share.properties加入到每个项目中，管理公共配置。一旦配置变更就可以自动在所有项目中启用。 spring:  application:    name: user  cloud:    nacos:      config:        server-addr: localhost:8848        shared-configs[0]:          data-id: share.properties          group: DEFAULT_GROUP          refresh: true
　　比如，woniu科技的公共配置内容包括：
　　环境配置
　　nacos地址
　　mq地址
　　redis地址
　　…
　　spring-boot配置
　　actuator配置
　　常用配置
　　mvc和json的日期格式
　　日志配置 总结
　　用下图总结上文所述，希望大家有所收获