前言
作为一名开发，经常面临着主动或被动切换业务做，有些时候切换至有一定相关联的另一个业务，本来做余额宝的被调到做证券。一些情况下是切换至完全相关的业务，如从商品切换到交易，甚至从电商业务切换至金融业务。在经常遇到这种的情况下，建立一个“快速熟悉陌生业务”的方法论就很重要了。下面经过个人思考，提出的一些不完善的想法。
一、划分模块
人的记忆和关系型数据库有些类型，较容易记住的大的关键点，而具体的细节可能想很久，甚至记不住。根据人的这种记忆方式，我们接触一个新的事务最好的方式应该就是分层，按照一定逻辑分几层，每层分多个模块，了解每层各个模块概念，然后再细分下一层子模块概念。这种思维方式有点像数据库的索引，符合人的思维习惯。
划分模块方式
模块是基于一定逻辑组织形式来划分的，只要按照逻辑来划分的话，划分模块的方式肯定有很多种，这里我提两种最容易的方式：业务功能，应用架构。
业务功能
按照业务功能性，对业务进行拆解，把复杂的业务进行拆分成功能单元，各功能单元再根据场景进行更细粒度的拆分。拆分有一个原则，要做到高内聚，低耦合。
应用架构
基本上应用都是分层的，下图就是最常见的应用的组织形式，当然很多应用组织形式会根据具体情况进行变化
二、梳理业务领域模型
对于大部分人结束新的业务的时候，相信最麻烦的就是周围人谈论的“专业词汇”，像之前听得什么，直销、代销，转托管，卡账，户帐这类词汇对于第一次听到人肯定蒙蔽。对于这一类词汇其实很多都是特定业务领域形成的简化术语，如果连这些业务领域内的概念的不清楚，那么根本不知道在讨论一个什么事。这类词汇存在于特定业务领域中，了解业务领域是相当重要的，统一大家的概念认知，统一大家在讨论的是一件什么事，在做的是一件什么事！！
所以我说的要了解业务领域，并不是指得DDD，充血、贫血模型。而是对业务进行一定抽象成一个或多个有关联的业务模型，对于这个模型有一定认知是需求讨论和方案设计的前提，很多时候某个业务域用到了其他业务域的模型，那么相对于相关联业务域的模型也要有一定认知。
如何梳理业务领域模型？
业务领域模型最底层的是数据库表极其字段，把表和表之间的关系，字段含义理清楚后，会有大概的业务轮廓。接着通过熟悉模块中核心的POJO的类极其字段能更对业务有更清晰一点的认知。当然这还不够，还需要花时间去看一些集团，网上的文章，关于其他人对业务的理解，其他人在技术如何设计和实现的。这个过程不是一蹴而就的，慢慢的会找到更深的理解，等到了能发现当前这个业务领域模型优点缺点，并构思出改进的方向，基本上就意味已经进入这块业务领域的专家了。
三、梳理业务调用链路
寻找业务入口，然后看代码。一般来说业务代码迭代很快，很多在写代码的时候没有考虑以后，经常被之后的需求给推翻调，亦或者经历过多个团队多人接手过，每个人命名、设计等等习惯不一样，所以这个过程比较痛苦。
如何梳理业务调用链路？
这里必须要提一下，traceId是个神器，自己实际操作一笔拿到traceId，在集团鹰眼或者蚂蚁云图上应用的调用链路基本上呼之欲出，但是具体逻辑细节还是要自己去看代码。这里看代码我理解两种模式，一种是自下而上，另一种是自上而下。我比较喜欢自上而下的看，这样顺着业务链路来理解比较简单，大部分情况下两者结合效果比较好。
自上而下
前后端不分离的PC页面，顺着页面实际操作入口去看，很简单前后端分离的PC页面、Ajax接口、无线端，和前端同学打好关系，多聊聊，喝喝咖啡，让前端同学帮忙去找入口，另外就是通过网络抓包找到调用入口，顺着代码往下看吧，少年。通过日志里面的traceId可以查到调用链路甚至到接口级别，这就更方便找到入口。一般情况下相同功能模块、对外的接口会放在一个大包或者pom模块下面。
自下而上
从数据库表入手，理解表模型，各字段含义，建立各表和字段之间的关系。
四、需求入手
一般情况下，公司不太会给太多空闲时间去看代码，且直接看代码多数情况下也没有那么直观感受，这时候结合一些比较完整的需求去搞，效果反而会更好。所谓完整的需求是指：尽量是完整模块的需求，或者能串联部分或整个链路的需求。切身体验零散的需求没有鸟用。