我们上面都是整理项目的大体框架，还没有涉及到具体的项目细节。这一部分，仍然不去涉及。如果说站在整个业务的本质上看，业务无非就是一堆代码运行在一堆机器上。那么站在单个项目来看，一个项目无非就是对数据库的增删改查操作而已，或者从使用者的角度看，一个项目就是输入一些参数得到一些返回结果。所以接下来我们要做两件事，一个是整理数据库表，一个是整理Controller层的所有接口。
这里首先要选择一个核心项目去看，众多项目中一定有一个是核心项目，先从这个开始看起。
如果数据库的表比较少，那我们拿工具导出来表结构，一个个看就行了，这个不难。但如果数据库表特别多，我们首先要将表名全部导出，筛选出那些核心的表。这里导出表名、筛选表以及后面的分析表字段，不妨给自己做个工具，我在遇到一些很麻烦的或者感觉以后还可以通用的事情时，就会做成一个小工具，放在一个我给自己起名为javamate的程序中，这些小工具逐渐积累起来你会发现今后有意想不到的方便。话说回来，如何判断哪些是核心表呢，不要着急，我们首先排除掉一些没用的。拿我在公司分析的系统来说，一共150多个表，其中有好多copy结尾的是备份，flow结尾的是流水，rel结尾的是中间关联表，statistics结尾的是数据统计表，log结尾的是日志表，config结尾的是配置表。等等。排除掉这些对核心业务理解无影响的表之后，所剩的也就20来张表，再根据他们的名字，可以看出好多表是属于一类的，比如order表就有各种order，按类别再分出来也就四五类，再分析起来就不难了。当然如果是更大的体系结构，那就要再不断做拆解。
再具体分析这些核心表字段之前，还要做一件事就是找出表中间的关系。如果表b中有个字段叫比如a.id，那么b和a就是一对多的关系，如果两个表有rel中间表，那二者就是多对多的关系，起码从逻辑上讲是这样的。这个分析过程我也是做了个小工具，通过程序来判断的。
到此，你就对整体的数据库结构有所了解了。根据表名也能对表的大致内容有所了解，接下来就是针对具体的表，看里面具体的字段和前人给出的备注，这个过程就没有技巧了，要耐心，要慢慢熬。
五. 整理Controller层接口当你对数据库表做了以上到了解后，你基本上对这个系统能提供什么服务了解到差不多了。这个不论你的代码长什么样子，数据库摆在那里，其实能提供的服务就已经差不多出来了，对于有经验的人来讲，代码的业务逻辑也大致能猜到个八九分。我们梳理了大后方，那接下来就是把最前端和别人交互的部分搞清楚，这样掐头去尾，整个项目就解剖的差不多了。
这里我也给自己做了个小工具，扫描出所有的controller层的接口，展示出方法名，路径名，参数列表和返回值等，但可惜没能展示注释，有大神可以帮我想想。和数据库一样，如果接口很少那么一个个看，如果特别多，还是先找出比较核心的几个方法研究。这里我用的是postman，把要研究的接口访问保存起来，并且添加访问成功和失败的Example。这里我推荐自己开发的时候也把postman用起来，越详细越好，postman不只是可以简简单单访问你的接口，还能做批量测试，还可以生成api文档用于和前端交互。这样你不但测试了自己的接口，还省的写文档了。而且postman还有个好处就是可以给自己的接口mock一个服务，这样即使你的接口挂了，或者你的接口根本就没写好，你可以让前端人员先访问你的mock，完全不影响前端边测试边开发，这才是真正的前后端分离嘛。
六. 重新理清项目间的关系好了，这时候每个项目你已经大致了解，最起码调用的效果，数据库所能提供的服务，你是清楚的。这个时候，要重新整理下项目之间的关系。
根据之前的接口名称，详细了解下项目间的调用关系。理不清的部分去问老员工，这时候你带着自己的了解问，他们也能给出更多的信息。
看看每个项目中用到的中间件，主要是mq服务，看看谁是生产者，谁是消费者，以此来了解关系