有关APP架构设计的思路

设计架构主要看团队人数,团队越来越大,那么只能通过业务解耦
每个业务一个Git仓库,每个业务都可以生成Pod库
MVC  MVVM  MVP 都是通过改变视图,数据model的通信方式,达到代码解耦
大型项目解决模块粒度划分、分层、多团队协作
开发遵循原则: 1.单一功能  对象功能要单一  不要添加多个功能
                         2.开闭原则   扩展是开放的   修改是封闭的
                         3.子类对象是可以替代基类对象的
                         4.接口的用途要单一,不要一个接口根据参数不同实现多个功能
                         5.方法依赖于抽象 , 不能依赖于实例, 高层业务都是依赖协议
采用组件化,通过CocoaPods包进行管理
 分层分为三层:
1.底层无关业务的基础组件,网络、存储等
2.中间层一般都是些通用业务组件  账号、埋点、支付、个人页等
3.最上层就是迭代频繁的业务层
组件化设计方案分为协议式和中间者两种架构
协议式架构设计采用的协议式编程
缺点是灵活度不够   而且我感觉没有中间的调度,耦合度有点高
中间者架构采用中间者统一管理  如CTMediator
CTMediator是运行时解耦,其实也是通过消息转发机制的三步走来实现的
本质一个方法来接受action、action、params.为了便于编码,通过Category来改善参数字符串问题
现在有人讲微服务,插件化,其实有时候在代码功能方面就可以考虑插件化如滴滴开源的Echo
我的CTMediatorTest

有关架构,我会不断更新我的一些想法,下一步会加入一些有关设计模式的思路