iOS 架构.png
一、好的架构漫谈
1.代码整齐，分类明确，没有common，没有core
不要让一个类或者一个模块做两种不同的事情，一方面不适合未来拓展，另一方面也造成分类困难
不要common，不要core：每个人认为的common和core不一样，同时软件是有生命的，会不断的迭代成长。如果有了common和core最后随着业务和需求的不断变更，一定会使得代码变得一团糟。
2.不要用文档，或者很少用文档就能让业务方上手
开发时间紧
需求多
尽可能的使我们的API名字可读性强
3.思路和方法要统一，尽量不要多元
方案要坚定，不要摇摆
记录方案的背景，概要设计，详细设计
4.没有横向依赖，万不得已不要出现跨层访问
横向依赖杜绝
跨层访问有时候无法避免：网络底层里面信号从2G变成了3G变成了4G，这是有可能需要跨层通知到View的。但这种情况不多，一旦出现就要想尽一切办法在本层搞定或者交给上层或者下层搞定，尽量不要出现跨层的情况。跨层访问同样增加耦合度，当某一层需要整体替换的时候，牵扯的面太广。
5.对业务该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件
限制：比如网络请求数据回调使用统一方式比如Delegate或者Block
灵活：如果是设计一个ABTest相关的API的时候，我们又希望增加它的灵活性，使得业务不光可以通过Target-Action的模式实现ABTest，也可以通过Block的方式实现。尽可能满足灵活性，减少业务方的使用成本
6.易测试，易拓展
易测试需要提高模块化程度，尽可能减少依赖关系，便于mock测试。
高度模块化容易拓展
7.保持一定量的超前性
产品需求：了解产品未来的发展方向
技术方案：组件化、动态化、跨平台
8.接口少，接口参数少
越少的接口越少的参数，就越能降低业务方的使用成本
满足业务方的充要条件
9.高性能
重要但是不是第一要素
苹果产品的性能已经足够好
不能因为优化性能影响稳定性
10.架构分层
按照业务分层：三层、四层。逻辑上有几层就恶意分为几次。每层具体做什么，叫什么没有特定的规范。这主要针对模块分类而言
按照数据流动：MVC、MVVM
业务分层&数据流动结合：
三层架构：数据管理者、数据加工者、数据展示者
笼统来说，软件只会有三层，每一层扮演一个角色。其他的第四、第五层一般都是这三层里面的其中之一分出来的，最后都能归纳为这三层中的某一层，所以三层描述比较普遍
