目录
[（一）引入 pom 文件与修改](#（一）引入 pom 文件与修改)
[（二）创建 Spring Boot 启动类](#（二）创建 Spring Boot 启动类)
[（一）引入 domain 包实体类](#（一）引入 domain 包实体类)
[（二）迁移 mapper 文件](#（二）迁移 mapper 文件)
[（三）调整 service 层代码](#（三）调整 service 层代码)
[（四）引入 controller 层代码](#（四）引入 controller 层代码)
引言
这是我在学习springcloud的过程中进行项目拆分的一点点小感悟，因为觉得有意义所以就上传了，希望大家看到后可以有不同的感受，仅此
一、选择聚合结构进行拆分的优势
如果一开始是一个单体项目的话我们可以使用聚合结构，就在单体架构的项目结构下去拆分 ，这项不仅我们可以很方便的去引入我们的pom文件，还可以继承我们的父pom文件配置，而且还可以很方便我们去copy我们这个微服务项目下的业务代码。
二、微服务模块创建步骤
（一）引入 pom 文件与修改
在父project工程下创建module来引入微服务。首先要做的就是引入pom文件。由于微服务追求高内聚低耦合，所以需要对引入的pom文件进行清理，删除不必要的依赖，只保留与该微服务紧密相关的依赖项，以确保微服务的独立性和简洁性。
（二）创建 Spring Boot 启动类
启动类是微服务运行的入口，我们可以选择手写，也可以从其他相似项目中复制。推荐copy因为这些代码格式都是固定的，没必要手写
（三）搭建基本包结构
接着，我们开始创建一些基本的包，如service、controller、mapper、domain等。service包用于存放业务逻辑处理代码，实现具体的业务功能；controller包负责接收外部请求，并将请求转发给相应的service进行处理，同时将处理结果返回给客户端；mapper包主要用于定义数据访问接口，与数据库进行交互；domain包又有dto，po，vo等，用于表示与数据库表结构相关的实体。后续可根据具体业务需求，自行增加我们的包，就比如interceptor，until，aspect
三、配置文件的引入与调整
这样做之后，我们需要引入我们的配置文件，配置文件主要是我们的依赖所需要的配置，我们视情况而改动，但是我们的微服务端口号port和名字一定要改，以及swagger的一些名字要修改。
四、业务代码的引入与注意事项
在引入我们的业务代码的时候，我们要注意自底而上的去构建copy代码
（一）引入 domain 包实体类
按照自底而上的构建方式，首先引入domain包下的实体类。这些实体类是与数据库表结构对应的对象，引入后，我们一定要一定要仔细的检查是否存在包层级、包引入等方面的问题，确保实体类能够在新的微服务环境中正常使用。要不然特别麻烦，会一直出错
（二）迁移 mapper 文件
在domain文件copy完成之后，我们可以接着复制mapper文件。同样，要对mapper文件进行全面检查，因为在从单体项目迁移到微服务的过程中，包的结构和依赖关系可能发生变化，需要确保mapper文件中的接口定义、SQL 映射等内容都能正确适配新的环境。
（三）调整 service 层代码
service层代码通常是最最最最需要改动的部分，因为业务代码都在这里写着。由于微服务强调高内聚低耦合，在将service层代码迁移到新的微服务中时，要特别注意包的依赖路径已经发生改变。需要对代码进行梳理和重构，将与该微服务紧密相关的业务逻辑保留在本服务内，去除不必要的耦合，使每个微服务都能独立地完成特定的业务功能。
（四）引入 controller 层代码
最后引入controller层代码。在COPY过程中，要确保请求的路由和处理逻辑正确无误，能够准确地将请求转发给相应的service层，并将处理结果以合适的格式返回给客户端。
五、实践感悟
这时候我们的微服务拆分基本就已经完成了。很多都是细节上的，但是只要我们抽丝剥茧，一层一层的去构建，这个微服务肯定会构建完成了
当然我们仅仅是将一个业务模块从我们单体项目中拆分了出来，当我们全部拆分完，高内聚低耦合的时候，我们还需要