业务组件虽然能实现代码隔离，多人开发减少影响，增加新功能不减少对老功能的影响。但是它也有很多缺点，甚至特别的项目无法使用业务组件化设计。业务组件化有下面的缺点：
1.业务组件化的代码通常不是自测试，非严格测试，只是对文件头文件进行检测，可能对方法实现的.m文件不深入检测。造成业务组件化的方法本来就是错误的，但是项目能正常运行，但是不报错。这个就让人很奇怪了，闪退了就不一定知道。如业务组件化里的这个函数竟然不报编译错误。
- (NSString *)totalNum { if (self.datas.count > 0) { LKSameCityButtonModel *model = [self.datas objectAtSafeIndex:self.selectedIndex]; return model.title; } else { @"0"; } }
2.业务组件化多了，维护时间成本很高，经常打包是一个人修改了，另一个人没有拉最新代码，sourcetree的提示更新也不是那么及时准确，我们十六个业务组件导致每次打包漏代码，一个一个库拉代码又很费时间。
3.业务组件访问图片等资源需要拼接地址，不同的库出现重名的相同图片资源也不报错误徒增app大小。
4.多个业务组件出现相同的文件可能不报错，也可能报错，有可能因人而已，我们出现过一次，不知道是特例还是常规问题。
4.若上马甲包，采用工具混淆时，无法使用混淆工具混淆业务组件。大家知道使用业务组件的工程，所有主要逻辑都在业务组件里，主工程通常是一个空壳或很少的代码，所以只能把所有的业务组件撤销合并成一个工程，业务组件的工程合并成一个工程工作量很大，资源访问要重新整改，搞不好取到的图片为空还不报错。
综上所述：不是所有的工程都适合业务组件，业务组件不能太多，多了要合并，减少维护成本。
