推薦閱讀：
一、爲什麼需要一個好的代碼結構
好的代碼結構並不僅僅是爲了看上去清晰，它更像是我們對一個系統的拆解和組裝。
好的代碼結構可以讓你在遇到代碼交接這種天理不容的情況時，減少提刀砍人的可能性。
好的代碼結構可以讓多人協作開發更容易，而不會纏纏綿綿到天涯，再相愛相殺。
我們經常形容一個壞的代碼結構，像屎一樣。
我們稱它爲一坨，說真的，接手過爛代碼之後，真的找不到比屎更能描述自己感受的詞了。
“屎”代表着混亂，一坨，各種雜質。接手一堆爛代碼的難度就像是用一坨屎來做沙畫。
有時候我們還會用一團毛線來形容代碼，大概是這樣的。
對的，這種感受是絕對不會錯的。而我們要做的就是把這團毛線，變成像瑞士軍刀一樣的清晰。
你們覺得哪個更有成就感？
二、什麼樣纔是一個好的結構
好的結構應該保持單一職責。
好的結構應該是通用的。
好的結構應該是有明確定義的。
這其實就是所謂的腳手架提供的最大的價值，一般而言，Java，Android，IOS都有一套明確的框架體系，JS本來沒有，後來有了，然後。。他們就打起來了。
就像。。。他們一樣。
該噴火的噴火，該噴水的噴水，每個人分工都很明確。
三、每一個分類代表什麼含義
1.Model
Model是模型，一般而言，會有人分的更細，VO，DTO等等。我並不推薦分的更細，這個Model常常和持久化的數據一一對應，如Mysql和MongoDB。
Model承載的作用就是數據的抽象，描述了一個數據的定義，Model的實例就是一組組的數據。整個系統都可以看成是數據的 流動，既然要流動，就一定是有流動的載體。
這個紅圈標的就是Model。它就應該是一個純數據的集合，就是被各種東西傳來傳去，被各種加工處理的數據團。
通常會有很多Model，一條業務流就是對應一條或者多條數據流，拿知乎爲例子。
文章是一個Model，一般叫Article，包括Title，Summary，Author，Content等等。
評論也是一個Model，一般叫Comment，包括Content，userID等等。
對於初學者而言，第一個要學會，就是建模，把業務邏輯映射成數據模型。
2.Util
Util是工具的意思，一般來說，常常用來描述和業務邏輯沒有關係的數據處理。
Util一般要和私有方法對比：私有方法一般來說是隻是在特定場景下使用的，私有方法越多，代碼結構越亂。常見的重構策略就是首先從一個越長行數的代碼裏抽象出若干個私有方法，然後再抽出公用的Util。
如果有可能，儘可能地少用私有方法，而是把它換成一個公用的Util，代表他和業務邏輯是不相關的。通常命名也是ArticleUtil，CommentUtil之類的。
像這種打包，不管是充氣娃娃還是別的什麼東西，都打包。你可以理解爲圖中的黑衣人就是一個Util。
某種程度上也會跟Service有點接近。但是Service一般而言，都是包含有業務邏輯的，很少能做單元測試。
Util一般來說，就是一個明確的輸入和一個明確的輸出結果。單元測試中，多數也是來測試Util。
積累好自己的Util是一件很重要的事兒。
3 Service
Service比Util的概念大很多，它的重點是在於提供一個服務。這個服務可能包括一系列的數據處理，也有可能會調用多個Util，或者是調用別的服務。總歸一句話，就是，有什麼事情，你來找我。
就像這個圖上的妹妹一樣，她就是一個Service，她能提供什麼樣的服務？這個是必須定義好的。如果是洗腳，她要幫你脫鞋，要端盆子燙你的腳。這裏面，你的腳就是一個Model，盆子裏的水相當於Util，不管裏面放進去啥都能燙一燙。
幫你脫鞋可以是一個Service，也可以是一個私有函數，也可以是一個Util。看你的是讓這個小妹妹幫你脫，還是別的小妹妹脫，還是自動脫鞋機。
如果是你自動脫。。。說明你在Model裏面加上了功能，你的腳就不是一個純粹的數據模型了，而是一個包含業務功能在裏面的充血模型。
這樣不好。老老實實讓小妹妹幫你脫鞋不好麼。
4.Dao
Dao一般而言，都是用來和底層數據庫通信，負責對數據庫的增刪改查。
是的。他就是一個Dao。他從來不關心這些貨物要去哪裏，他只關心。入庫，出庫，查詢和更換。
所謂的CRUD就是創建，讀取，更新，刪除。
Dao最好都是要獨立出來。
到現在爲止，最佳實踐就是一個Service只對應一個Dao。Service會做一些額外的檢查，如貨物是否損壞，入庫單是否完整，等等等等。
我並不推薦在Service裏調用多個Dao，也推薦在Service裏調用多個Service，大多數情況下我都不推薦這麼幹。
具體原因以後再說，這也是一個開放性的話題。
現在我們分清楚了Model，Util，Service和Dao，可是誰來做總的調度呢？
5.Controller
控制中心，所有的指令，調度都從這裏發出去。
哪一個Service做什麼事兒，誰的數據提供給誰，一般而言，都是在Controller裏實現的。
Controller也是最常見的容易產生髒代碼地方，通常他們會把一些不該放到Controller裏東西也放進來。
大概的感覺就是這樣的。
幹嘛的都有。想想如果打小針，抽血，查尿也混雜到門診大廳的感覺？
可是大部分人寫代碼就是這樣的。
四、是否適用於WEB，Android和IOS？
Java後臺是有很清楚的結構的，畢竟在JSP裏寫Sql語句的蠻荒時代已經過去了。
Android本身就是一個良好的框架體系，基本上問題也不大，最多就是MVP和MVC的差別之類。
IOS雖然沒有官方提供這種框架體系，特別是很多人喜歡直接在Dict裏用key取數據，這本身就破壞了代碼的層次性。
但是畢竟是有李明傑提供的Json解析Util,只是各家要求的力度而已。
最難以理解的是WEB，也就是JS。
我不是在黑JS，我是在黑JS程序員。分層結構一直都不是JS社區裏最注重的，在JQuery時代更是如此，不管是Html還是JS還是CSS混在一起是正常的。
那個時候叫插件，現在改名了，叫組件。
你很難在JQuery裏找到一套清晰的分層結構，就跟十幾年前所有的人都在Jsp裏寫邏輯語句的道理差不多。
直到google的大神偶爾溜達過來一看，咦？你們怎麼還在刀耕火種？我來給你們加點現代感的東西吧。
於是Angular橫空出世，一次性地構建了一個清晰的框架結構。每次看到Angular的時候都忍不住 驚歎，原來前端代碼也可以這樣！
而原來的感覺就是這樣。。。
現在基本上可以分成兩大陣營，一個是React和Vue，一個是Angular。
React和Vue本身更偏得於插件化，哦，不，組件化。所以他們需要便宜桶，來拼接整個前端的架構體系。
Angular卻是有典型的Java架構風格，妥妥的硬漢子。
所以，實際上說，這套體系也是可以應用在WEB上的，就像Android和IOS一樣的，但是你喜歡，或者不喜歡，自己選啦。
五、進一步地學習的話，是要學習系統架構麼？
是的。進一步要學習，並不僅僅是學習系統架構。
這裏還沒有講到Service的設計，互相之間的調用，解耦，服務之間的通信和管理。
消息隊列這個神器還沒有登場，MongoDB這種戰略要塞也沒出場。