项目结构主要在MVVM的基础上进行分层
- Model负责定义数据模型等
- ViewModel 负责沟通Model与View等
- ViewController 负责展示等
当项目需要决定按哪种使用哪种目录结构的时候，这里探讨一下三种情况
- 先分层，再分模块
- 先分模块，再分层
- 直接分层
1. 先分层，再分模块
这种结构能够快速定位到某一层的问题，
这种方式更注重每一层之间的耦合性
但是无法解决common模块的归类问题
2. 先分模块，再分层
这种结构能够快熟定位到某个模块的问题，
这种方式注重每个模块之间的耦合性，
依然无法解决common模块的归类问题
3. 直接分层，不分模块
这种结构能够解决common模块归类的问题，因为没有模块，所以不需要归类
这种结构每一层的内容可复用性更强，因为不受模块的约束，每一个内容可能与其他层的多个内容相关联
但是model、view、viewModel就是三个大染缸，每一层的内容无法表达它所负责的模块，甚至连View都无法明确它会应该展示哪一个界面，因为缺少约束了，form view能够用于修改用户信息view，也能够用于用户调查view,只要viewmodel能够提供不一样的数据，而使用其他方式，form view更可能再common中，
归类common模块存在的问题
1. common模块的内容抽离问题
common模块中已经存在的模块与其关联的业务发生了调整，原来可以放在common中的模块不再需要放在common中，这时候需要考虑是确保common的纯净，还是程序的稳定，common模块中与之关联的业务可能离开，也可能再回来，如果反复抽离common模块的内容会让common不够稳定，但是如果不抽离common则无法保证common的纯净
这种情况也许需要妥协，让common尽可能的纯净，首先保证程序的稳定，common中做到只加不减，然后确保common的纯净，控制模块随意加入common中，
2. common模块的界定
如果无法决定common的界定问题，那么先从目的开始，common的目的是为了能够让多个模块共用common模块的内容，反之就是每个模块可以选择使用common中的内容，也能够自己单独实现某个内容，当无法界定的时候，就去实现其目的，当开发者开发完一个模块，然后通过一种甄别手段，title决定或者团队多人都有用到这个模块的需求，然后开发者负责把模块的共享达到让多个模块共用这个模块的目的
3. 模块的纯净问题
当使用common模块之后，势必会让某个模块不再纯净，它除了转场外需要在其他地方使用到其他模块的内容，这势必也会增加维护成本，开发者无法一眼确定这个模块是否有用到common中的内容，
结合使用
因为每一层的耦合度明显低于每个模块之间的耦合度，viewModel通知view，多于viewModel通知viewModel，所以结合先模块再分层、直接分层，
为了解决共有内容归类的问题，那么要明确哪些内容更可能共有，然后再考虑取缔其按模块约束带来的便利，
- 如果把view去掉模块结构，首先面临的问题是无法表现主模块与子模块的层次问题，某个view可能有多重身份，以微信为例，它即可能是发现界面，又可能是“我”界面，只要它取到不一样的数据，它就能表现多重身份，但是这种情况下耦合性就太强了，当“我”界面发生了变化，那么很难单独去修改“我”界面而不动到“发现”界面，所以暂且把view留着
- 如果把viewModel去掉模块结构，面临的问题依然是每个viewModel职责不清，复用viewModel会增加项目的耦合度，而这种耦合度在后期项目修改的时候很难单独去抽离复用的内容
- 貌似只有Model可以抽离，Model负责定义数据模型，那么如果一个UserInfoModel可复用的情况就很多，所以抽离Model不按模块分层视乎是对解决共有内容归类伤害最小的一层，但是即使如此，依然存在无法直接表现出ViewModel处理了哪几个Model的问题，
其他方法
每个模块都负责实现仅仅操作自己模块的内容，common模块定义的内容不能直接使用，每个模块需要使用common的内容时候，必须在自己模块定义一个相同的子类，子类通过继承common内容得到common内容的方法/属性，这样能够适当的减少归类问题，因为无需再去考虑把common内容归类，common内容被弱化，而模块目录中存在完整的内容，不再过度依赖common中的内容
但是这种方法会导致项目变得越来越臃肿，带来的好处是减低后期维护成本以及解决common内容归类的问题
