背景
看過很多XCode的工程文件夾，整體感覺很亂担锤。其實蔚晨，當時整理的人一般都是花了心思的，也都有各自的道理。但是铭腕，一般工程都經過N多人接手银择，每個人劃分文件夾的思路都不盡相同，時間久了累舷，自然就顯得亂了浩考。
主要的原因就是文件夾劃分的原則有好幾個，比如按照類別劃分被盈，有Controller析孽、view等；比如按照邏輯功能劃分只怎，有理財袜瞬、保險等；比如按照數據格式分身堡，有網絡邓尤、數據庫等。
所以贴谎，要解決“文件夾亂的表象”汞扎，最重要的是統(tǒng)一文件夾分類的標準。
整個應用
整個應用層級考慮的是公司間的協(xié)作擅这，部門間的協(xié)作澈魄，甚至是部門內小組間的協(xié)作。從抽象到具體仲翎，分三步走一忱。
Step1 按照開發(fā)方式分大模塊
Native是必須的，這是主體模塊谭确，入口模塊
H5雖然性能和體驗差一點，但是靈活票渠，并且有PC端BS架構的成功經驗逐哈，所以目前這一塊一直很火。
有一些事情需要其他公司做问顷，比如支付昂秃、AR等；以framework方式提供杜窄，從界面到邏輯再到數據是完全獨立的模塊肠骆。這個是插件化的思路。主程序和插件之間適合用類似url的信息傳遞方式scheme://host?query塞耕，一般用來單向拉起插件蚀腿，也符合服務化的潮流。
還有現在出現的React Native，目前還沒有形成趨勢莉钙，不過熱度很高廓脆。如果流行起來，那么就是從Native再切一塊出來磁玉。
Step2 Native部分分層
Native開發(fā)是最耗時停忿，靈活性最低的部分，并且還要依賴界面資源和數據資源蚊伞，所以考慮分層席赂。根據UI和后臺這兩個依賴，分三層时迫。
界面層是最簡單颅停，也是最復雜的一層。采用MVVM的思想别垮，盡量切薄便监，隨時應對UI設計師的變化
數據層依賴后臺API，相對穩(wěn)定碳想，但是很可能由于部門合作不暢烧董，溝通不充分，導致延遲胧奔。所以逊移，這一層也應該切薄，應對API的變化龙填。
中間的邏輯層是客戶端開發(fā)完全掌控的胳泉，這部分一般是業(yè)務邏輯。這一層盡量厚岩遗，并且封裝要好扇商，容易復用，形成部門資產宿礁。
邏輯上分三層案铺，但是物理上就兩層：主體程序和各種framework。邏輯上的層次是通過framework之間的依賴關系來體現的梆靖。
單個framework
一個單獨的framework控汉，理論上應該功能簡單，比較小
就按照功能分模塊返吻，分類標準單一姑子，結構簡單
如果有界面，那么一個Storyboard + 一個imageset + N（N<7）個功能型Scene（controller）子文件夾测僵，構成一個模塊
如果是一些公共的view或者控件街佑，那么就統(tǒng)一放在一個文件夾中，比如componant
獨立的邏輯功能就單獨放一個文件夾中
