转自http://www.mrpeak.cn/blog/module/
组件是由一个或多个类构成，能完整描述一个业务场景，并能被其他业务场景复用的功能单位。
组件的定义
首先需要对组件进行定义，叫组件也好，模块也罢，我们姑且认为我们讨论的范畴是【独立的业务或者功能单位】。至于这个单位的粒度大小，需要工程师自己把握。当我们写一个类的时候，我们会谨记高内聚，低耦合的原则去设计这个类，当涉及多个类之间交互的时候，我们也会运用SOLID原则，或者已有的设计模式去优化设计，但在实现完整的业务模块的时候，我们很容易忘记对这个模块去做设计上的思考，粒度越大，越难做出精细稳定的设计，我暂且把这个粒度认为是组件的粒度。组件是由一个或多个类构成，能完整描述一个业务场景，并能被其他业务场景复用的功能单位。组件就像是PC时代个人组装电脑时购买的一个个部件，比如内存，硬盘，CPU，显示器等，拿出其中任何一个部件都能被其他的PC所使用。
所以组件可以是个广义上的概念，并不一定是页面跳转，还可以是其他不具备UI属性的服务提供者，比如日志服务，VOIP服务，内存管理服务等等。说白了我们目标是站在更高的维度去封装功能单元。对这些功能单元进行进一步的分类，才能在具体的业务场景下做更合理的设计。按我个人经验可以将组件分为以下几类：
- 带UI属性的独立业务模块。
- 不具备UI属性的独立业务模块。
- 不具备业务场景的功能模块。
第一类是Limboy，Casa讨论较多的组件，这些组件有很具体的业务场景。比如一个App的主页模块，从Server获取列表，并通过controller展示。这类模块一般有个入口Controller，可以通过Push或Present的方式作为入口接入。电商类App的大部分场景都可以归于这一类，Controller作为页面的基本单位和Web Page有很高的相似度，我想这也是为什么蘑菇街会采取URL注册的实现方式，用URL来标记本地的每一个Controller，不仅方便本地的跳转，还能支持Server下发跳转指令，对运营团队来说再合适不过。从理论上来说，组件化和URL本身并没有什么联系，URL只是接入组件的方式之一，这种接入方式还存在一定局限性，比如无法传递像UIImage这类非primitive数据。这种局限性在电商app业务环境下，会带来多少副作用值得商榷，按我的经验，在完整独立的业务模块间传递复杂对象的场景并不多，即使有也可以通过memory cache或者disk cache来做中转。我没记错的话，之前天猫无线客户端不同业务模块间跳转也是通过URL的方式来实现的，有个类似Router的中间类来出来URL的解析及跳转，并没有Mediator去对组件做进一步的封装。以URL注册方式来接入组件，在副作用小，业务运营方便的背景下，蘑菇街的选择或许并不能算作‘’错误的方向“。
第二类业务模块不具备UI场景，但却和具体的业务相关。比如日志上报模块，app可能需要统计用户注册模块每个Controller进入的路径，便于分析每一步用户的流失率。这类业务模块如果要用URL去表达和接入会显得非常变扭。试想下通过如下的代码调用启用日志：
[[MGJRouter sharedInstance] openURL:@"mgj://log/start" withParams:@{}];
这也是蘑菇街以URL方案来实现组件化不合理的地方，按Casa的分法，组件被调用分为远程和本地，这种日志服务的调用是本地类型的调用，用URL来标这类记本地服务颇有些绕远路的感觉。
第三类模块和具体的业务场景无关，比如Database模块，提供数据的读写服务，包含多线程的处理。比如Network模块，提供和Server数据交互的方式，包含并发数控制，网络优化等处理。比如图片处理类，提供异步绘制圆角头像。这些模块可以被任意模块使用，但不和任何业务相关。这种组件属于我们app的基础服务提供者，更像是一个个SDK，或是toolkit。我不知道蘑菇街是怎么处理这类组件接入的，很明显URL的接入方式并不适合。我们通过Pods使用的很多著名第三方库都属于这一类，像FMDB，SDWebImage等。
接下来我们再看看各家方案对上面三种组件的接入能力及优缺点。