一般做法
在小规模的app中，我们直接import其他业务的某个View Controller， 然后直接push或者present。
容易引发的问题
一个view controller背后关联的某一个或者多个业务。直接import会在多业务组成的App中会导致业务模块之间的横向依赖。而横向依赖会导致：
- 当要开辟一个新业务时，如果已有各业务间直接依赖，新业务又依赖某个旧业务，就导致新业务的开发环境搭建困难，因为必须要把所有相关业务都塞入开发环境，新业务才能进行开发。影响的是新业务的响应速度
- 当某一个被其他业务依赖的页面有所修改时，比如改名，涉及到的修改面就会特别大。影响的是造成任务量和维护成本都上升的结果
- 当一个需求需要多业务合作开发时，如果直接依赖，会导致某些依赖层上端的业务工程师在前期空转，依赖层下端的工程师任务繁重，而整个需求完成的速度会变慢，影响的是团队开发迭代速度
解决方案
依赖关系下沉。 采用Mediator中介者模式。
设计的关键：
- 设计中介者根据请求如何获取其他业务的机制。中介者需要知道如何处理请求，上哪儿去找到需要的页面。 中介者跟最多的业务有交互
- 设计一套通用的请求机制。请求机制需要跟业务剥离；请求者不需要关心被请求业务的接口。
苹果本身的URL Scheme机制，用于支持跨App的调用。在这个case里， 苹果系统是中介者， 单个的App是某个业务， URL Scheme就是这套请求机制。