流行的 Web 框架大多數(shù)是 MVC 框架，為了能夠?qū)?GUI 類(lèi)型的應(yīng)用進(jìn)行方便擴(kuò)展，將程序劃分為：
控制器（Controller）：負(fù)責(zé)轉(zhuǎn)發(fā)請(qǐng)求，對(duì)請(qǐng)求進(jìn)行處理。
視圖（View）：界面設(shè)計(jì)人員進(jìn)行圖形界面設(shè)計(jì)。
模型（Model）：程序員編寫(xiě)程序應(yīng)有的功能（實(shí)現(xiàn)算法等等）、數(shù)據(jù)庫(kù)專(zhuān)家進(jìn)行數(shù)據(jù)管理和數(shù)據(jù)庫(kù)設(shè)計(jì)（可以實(shí)現(xiàn)具體的功能）。
隨著時(shí)代的發(fā)展，前端也變成了越來(lái)越復(fù)雜的工程，為了更好地工程化，現(xiàn)在更為流行的一般是前后分離的架構(gòu)?？梢哉J(rèn)為前后分離是把 V 層從 MVC 中抽離單獨(dú)成為項(xiàng)目。這樣一個(gè)后端項(xiàng)目一般就只剩下 M 和 C 層了。前后端之間通過(guò) ajax 來(lái)交互，有時(shí)候要解決跨域的問(wèn)題，但也已經(jīng)有了較為成熟的方案。下圖所示的是一個(gè)前后分離的系統(tǒng)的簡(jiǎn)易交互圖。
對(duì)于復(fù)雜的項(xiàng)目，一個(gè) C 和一個(gè) M 層顯然是不夠用的，現(xiàn)在比較流行的純后端 API 模塊一般采用下述劃分方法：
- Controller，控制層，與上述類(lèi)似，服務(wù)入口，負(fù)責(zé)處理路由，參數(shù)校驗(yàn)，請(qǐng)求轉(zhuǎn)發(fā)。
- Logic/Service，業(yè)務(wù)邏輯（服務(wù)）層，一般是業(yè)務(wù)邏輯的入口，可以認(rèn)為從這里開(kāi)始，所有的請(qǐng)求參數(shù)一定是合法的。業(yè)務(wù)邏輯和業(yè)務(wù)流程也都在這一層中。常見(jiàn)的設(shè)計(jì)中會(huì)將該層稱(chēng)為 Business Rules。
- DAO/Repository，DAO層，這一層主要負(fù)責(zé)和數(shù)據(jù)、存儲(chǔ)打交道。將下層存儲(chǔ)以更簡(jiǎn)單的函數(shù)、接口形式暴露給 Logic 層來(lái)使用。負(fù)責(zé)數(shù)據(jù)的持久化工作。
每一層都會(huì)做好自己的工作，然后用請(qǐng)求當(dāng)前的上下文構(gòu)造下一層工作所需要的結(jié)構(gòu)體或其它類(lèi)型參數(shù)，然后調(diào)用下一層的函數(shù)。在工作完成之后，再把處理結(jié)果一層層地傳出到入口，如下圖所示。
劃分為 CLD 三層之后，在 C 層之前我們可能還需要同時(shí)支持多種協(xié)議。thrift 、gRPC 和 http 并不是一定只選擇其中一種，有時(shí)我們需要支持其中的兩種，比如同一個(gè)接口，我們既需要效率較高的 thrift，也需要方便 debug 的 http 入口。
即除了 CLD 之外，還需要一個(gè)單獨(dú)的 protocol 層，負(fù)責(zé)處理各種交互協(xié)議的細(xì)節(jié)。這樣請(qǐng)求的流程會(huì)變成下圖所示的樣子。
