目前大部分项目不外乎就是在做:调API，展示页面，跳转别的地方再调用API，再展示页面...
写到这里好像写死了 。尴尬会...
app确实是在做这些事情，但是支撑这些事情的基础，就是架构需要做的事情了。
首先我们来想象一下，什么样的项目架构是好架构。
1.代码整齐，分类明确。
2.不用文档，或很少文档，就能让业务方上手。
3.思路和方法要统一，尽量不要多元。
4.没有横向依赖，万不得已不出现跨层访问。
5.对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件。
6.易测试，易拓展。
7.保持一定量的超前性。
8.接口少，接口参数少。
9.高性能。
这是我个人对项目架构的好坏标准，根据重要性排序。
代码整齐，分类明确
代码整齐是一个程序员的基本素质，先不说你搞定这个问题有多快，速度有多快，ider有多好，过几个月再回看这段代码，你还能看的懂吗 ？如果代码杂乱无章，随着一次次的拓展，你的项目能支撑多久？代码既是给自己看的，也是给别人看的，都不希望别人接手你的项目，各种吐槽吧 。前段时间美国程序员因同事代码不规范，枪击4名同事，不想死就好好规范代码吧。哈哈 。
不用文档，或很少文档，就能让业务方上手
没有人会有时间会去看文档，所以你得让你项目中api名字可读性强。oc已经把这个特性做到了极致。函数名长就长点，没什么太大的问题。
思路和方法要统一，尽量不要多元化
解决一个问题会有很多种方案，但是一旦确定了一种方案，就不要在另一个地方采用别的方案了。也就是做架构的时候，你得时刻记住当初你决定要处理这样类型的问题的方案是什么，以及你的初衷是什么，不要摇摆不定。你当初设立这个模块一定是有想法有原因的，要记录下你的解决思路，不要到时候换个地方你又灵光一现啥的，引入了其他方案，从而导致异构。
没有横向依赖，万不得已不出现跨层访问。
没有横向依赖是很重要的，这决定了你将来要对这个架构做修补所需要的成本有多大。要做到没有横向依赖，这是很考验架构师的模块分类能力和是否熟悉业务的。
跨层访问是指数据流向了跟自己没有对接关系的模块。有的时候跨层访问是不可避免的，比如网络底层里面信号从2G变成了3G变成了4G，这是有可能需要跨层通知到View的。但这种情况不多，一旦出现就要想尽一切办法在本层搞定或者交给上层或者下层搞定，尽量不要出现跨层的情况。跨层访问同样也会增加耦合度，当某一层需要整体替换的时候，牵涉面就会很大。
对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件。
必须要有能力区分哪些情况需要限制灵活性，哪些情况需要创造灵活性。比如对于Core Data技术栈来说，ManagedObject理论上是可以出现在任何地方的，那就意味着任何地方都可以修改ManagedObject，这就导致ManagedObjectContext在同步修改的时候把各种不同来源的修改同步进去。这时候就需要限制灵活性，只对外公开一个修改接口，不暴露任何ManagedObject在外面。
如果是设计一个ABTest相关的API的时候，我们又希望增加它的灵活性。使得业务方不光可以通过Target-Action的模式实现ABtest，也要可以通过Block的方式实现ABTest，要尽可能满足灵活性，减少业务方的使用成本。
易测试，易拓展。
要实现易测试易拓展，那就要提高模块化程度，尽可能减少依赖关系，便于mock。另外，如果是高度模块化的架构，拓展起来将会是一件非常容易的事情。
保持一定量的超前性
多多关注产品的动向，在合理的地方留一条路子。同时，在创业公司的环境下，很多产品需求其实只是为了赶产品进度而产生的妥协方案，最后还是会转到正轨的。这时候业务方可以不实现转到正规的方案，但是架构这边，是一定要为这种可预知的改变做准备的。
接口少，接口参数少
越少的接口越少的参数，就能越降低业务方的使用成本。当然，充要条件还是要满足的，如何在满足充要条件的情况下尽可能地减少接口和参数数量。
高性能
高性能非常重要，但是在客户端架构中，它不是第一考虑因素。
客户端业务变化非常之快，做架构时首要考虑因素应当是便于业务方快速满足产品需求，因此需要尽可能提供简单易用效果好的接口给业务方，而不是提供高性能的接口给业务方。
苹果平台的性能非常棒，正常情况下很少会出现由于性能不够导致的用户体验问题。
正常遵守oc的设计模式完全能满足。
那么如何设计适合自己的项目架构呢 ？
所有事情最难的时候都是开始做的时候，当你开始着手设计并实现某一层的架构乃至整个app的架构的时候，很有可能会出现暂时的无从下手的情况。
首先 找到你要清楚的知道解决哪些问题，找到必要条件。
你必须得清楚你要做什么，业务方希望要什么。而不是为了架构而架构，也不是为了体验新技术而改架构方案。以前是MVC，最近流行MVVM，如果过去的MVC是个好架构，没什么特别大的缺陷，就不要推倒然后搞成MVVM。
关于必要条件我也要说明一下，有的时候系统提供的函数是需要额外参数的，比如翻页的时候，当前页码也是充要条件。但对于业务方来说，这些必要条件还能够再缩减。比如翻页，其实业务方并不需要记录当前页号，你给他暴露一个loadNextPage这样的方法就够了。
搞清楚各问题之间的依赖关系，建立好模块交流规范并设计模块。
关键在于建立一套统一的交流规范。另外要注意的是，一定是建立一套统一的交流规范，不是两套，不是多套。你要坚持你的价值观，不要摇摆不定。要是搞出各种五花八门的规范出来，一方面有不切实际的炫技嫌疑，另一方面也会带来后续维护的灾难。
预测一下未来可能的走向，必要时添加新的模块，记录更多的基础数据以备未来之需
软件是有生命的，你做出来的架构决定了这个软件它这一生是坎坷还是幸福。
解决依赖关系中最基础的问题，实现基础模块，然后再用基础模块堆叠出整个架构
这一步也是验证你之前的设计是否合理的一步，随着这一步的推进，你很有可能会遇到需要对架构进行调整的情况。这个阶段一定要吹毛求疵高度负责地去开发，不要得过且过，发现架构有问题就及时调整。否则以后调整的成本就非常之大了。
打点，跑单元测试，跑性能测试，根据数据去优化对应的地方
最后用这些数据去不断调整你的架构。
