背景
看过很多XCode的工程文件夹，整体感觉很乱。其实，当时整理的人一般都是花了心思的，也都有各自的道理。但是，一般工程都经过N多人接手，每个人划分文件夹的思路都不尽相同，时间久了，自然就显得乱了。
主要的原因就是文件夹划分的原则有好几个，比如按照类别划分，有Controller、view等；比如按照逻辑功能划分，有理财、保险等；比如按照数据格式分，有网络、数据库等。
所以，要解决“文件夹乱的表象”，最重要的是统一文件夹分类的标准。
整个应用
整个应用层级考虑的是公司间的协作，部门间的协作，甚至是部门内小组间的协作。从抽象到具体，分三步走。
Step1 按照开发方式分大模块
Native是必须的，这是主体模块，入口模块
H5虽然性能和体验差一点，但是灵活，并且有PC端BS架构的成功经验，所以目前这一块一直很火。
有一些事情需要其他公司做，比如支付、AR等；以framework方式提供，从界面到逻辑再到数据是完全独立的模块。这个是插件化的思路。主程序和插件之间适合用类似url的信息传递方式scheme://host?query，一般用来单向拉起插件，也符合服务化的潮流。
还有现在出现的React Native，目前还没有形成趋势，不过热度很高。如果流行起来，那么就是从Native再切一块出来。
Step2 Native部分分层
Native开发是最耗时，灵活性最低的部分，并且还要依赖界面资源和数据资源，所以考虑分层。根据UI和后台这两个依赖，分三层。
界面层是最简单，也是最复杂的一层。采用MVVM的思想，尽量切薄，随时应对UI设计师的变化
数据层依赖后台API，相对稳定，但是很可能由于部门合作不畅，沟通不充分，导致延迟。所以，这一层也应该切薄，应对API的变化。
中间的逻辑层是客户端开发完全掌控的，这部分一般是业务逻辑。这一层尽量厚，并且封装要好，容易复用，形成部门资产。
逻辑上分三层，但是物理上就两层：主体程序和各种framework。逻辑上的层次是通过framework之间的依赖关系来体现的。
单个framework
一个单独的framework，理论上应该功能简单，比较小
就按照功能分模块，分类标准单一，结构简单
如果有界面，那么一个Storyboard + 一个imageset + N（N<7）个功能型Scene（controller）子文件夹，构成一个模块
如果是一些公共的view或者控件，那么就统一放在一个文件夹中，比如componant
独立的逻辑功能就单独放一个文件夹中
