一个好的或者成熟的架构首先要满足以下几点：
1，目录结构，清晰明了
2，高内聚，低耦合
3，灵活性强
4，可拓展性（可维护性）高
大家设想一下，当你的项目有上千个类（特别是OC，一个类有两个文件）后，如果你们公司有新员工入职，并且短时间内要开发和维护项目！他如何是好？
如果刚好你们的项目没有详细文档，一般是口口相传，那恭喜了，没个一段时间（具体熟悉时间根据个人能力，是否有该方面的经验，逻辑性。。。相关），基本上动不了代码，更不要说改东西了。
如果有开发文档，而且项目目录，与机构清晰，明了那么一定会事半功倍的。
So：开发文档很重要，这也是每个架构师必须经过的一个过程。
首先在 功能需求分析一文中，对项目的功能需求做一个全局掌握。然后书写开发文档。
这里先分析架构 ；
1，目录结构，清晰明了
有的人认为，开发嘛，代码才是最重要的！其实则不然。
代码固然重要。但是不要以为目录结构就不重要了。试想一下，你要在一千个文件中，更改或者添加功能。当你花了很长的时间找到你要更改的class文件，但是发现他里面结构混乱，还涉及到很多其他页面和class，不得不熟悉原来的业务逻辑了，并且我告诉你，就算你改完了，你也得测试好多遍，生怕其他地方会有问题。
而且 目录结构 是你架构设计的一个最直观的体现。什么意思？ 就拿MVC模式为例，是不是要把模型class放到Model文件下，把控制器放到control文件下。把视图放到View文件下。如果你只有十几个页面，那么别人一看到你的目录结构就知道是MVC模式了，而且目录结构，清晰明了。但是，只局限于少量的class。所以这点处理的就是在大项目中有比较清晰明了的目录结构
具体怎么处理目录结构，待我分析完项目结构后就一目了然了。
2，高内聚，低耦合
这也是本文的重点！
不管是模块化开发，组件化开发或者层级式开发，内部都是严格遵守这两原则。
在平时开发过程中，跳转到下一个页面，一般就是push 或者是 present到下一个页面。参数也通过属性传值的方式传入下一个页面。这时考虑到这样一个场景：
多人开发，甲：负责商品详情和支付模块，并且只提供了一个外部接口
乙：在商品列表开发完成以后，想看看后继续步骤，
这时 乙调用 甲提供的外部接口，实现了商品的展示，并且可以支付。完成业务逻辑。
这就是模块化开发，每个模块只提供特定的几个外部接口对外使用
开发了一段时间后，突然有个新需求。一部分的商品详情页发生了改变。也不会对其他模块有影响
其实换一种理解方式，链表，每一个完整的业务逻辑可以看成一个链表！！！里面的每个小模块可以看成一个节点。那么再去修改业务逻辑（增加，修改，删除）都可以很好的实现，灵活性高，拓展性强！
今天到这里！