从搭配开始
一个想中业务不一样导致项目大小不一样，但是架构的事情就是不管多少业务，大体的脉络就是统一，一个项目架构不统一，除了说明合作的人没有沟通，还有一个说明，项目历史悠久。
如果原因吐槽的员工一般都是从以上两点开始吐槽，轻者小吐，重的多残的都有。
一下代表个人意见，如有不同，欢迎留言
先从一个简单的页面开始
比如列表，或者有用户交互的输入页面。
如果上一篇文章说的，网络层的标准是逻辑处理层的数据处理问题的难易程度问题评判标准。
最表层的业务
如仿写爱范首页的业务，这里仅仅是简单的基本，比如，独立的滚动试图，功能控件，更多的独立view。
多业务的组合
一个项目必然会有多个单独业务组成，这也是组件化最爱利用的地方，但是，和我之前比较反对多代码嵌入业务的的想法一样，代码量+扩张性+易迁移 是我评判代码好坏的标准，代码的质量肯定是必要条件，但是根据以往的经验，在iOS开发过程中，能做到以上3点的，基本质量不会差。
这里拿借贷业务举例为啥，因为借款类app 的业务都很固定，可以多下几个借款类的，业务都一样。
这里的架构根据业务，前面说到独立，其实最重要的是这里独立
如公司产品说，要加独立业务了，那么这里的文件夹就要开始变化了，如果大模块比如交友，直播等，最直接的试图控制就在这里。
比如登陆的模块-这个复用性很高的模块
这里mvc 和mvvm 标准很简单，就是代码量，为了架构而架构，还是算了。
配套的业务的服务
这里说明一下TBFrameController，我是真心不知道起什么名字了，里面自定义的基础tabbarController，baseViewController，欢迎页面，等等，看自己爱好吧。
小结
文件夹配置和单一业务配置，以目前我自己的实践，这个配置是最高效和灵活的，也是最容易维护的，因为文件夹根据从全到细的分层，很容易让新入职的人员上手，这样降低了企业的用人成本，和人员的开发时间。
从低版本到高版本，在较短的时间进行磨合。根据产品的需求能够快速迭代。
