在專案的開始階段，一件必不可少的的事情就是就是確定程式碼的分層和架構。該分層和架構在一定程度上決定了未來整個專案的程式碼風格和維護性，對於專案的長期維護，程式碼架構的設計是一件非常重要的事情。
在介紹程式碼架構的設計之前，首先我們先談論下為什麼程式碼架構的設計師是一件非常重要的事情。

為什麼要有程式碼架構

簡單來講，程式碼架構是為了提供更好的可讀性和可維護性。

提高可讀性和可維護性

大家可能還記得剛開始寫程式碼的時候，所有的程式碼都會集中在一個檔案，甚至一個函式中，比如：

# main.py

def main(args: List[str]):
    input args validation...
    ...
    do first thing...
    ...
    do second thing...
    ...
    do third thing...
    ...
 

隨著需求的增長，程式碼量的擴大，這樣的程式碼是很難閱讀和進行維護的，於是我們會使用重構的手段去讓程式碼更便於維護和閱讀：

# main.py

def do_first_thing(args: List[str]):
    ...

def do_second_thing(args: List[str]):
    ...

def do_third_thing(args: List[str]):
    ...

def validation(args: List[str]):
    ...

def main(args: List[str]):
    validation(args)
    do_first_thing(args)
    do_second_thing(args)
    do_third_thing(args)
 

進一步，我們將程式碼分散在不同的檔案、資料夾中，通過良好的命名，我們甚至可以在不去看具體的程式碼實現的情況下，僅僅通過檔名就能判斷出在做的事情：

│   main.py
│
├───job
│       first.py
│       second.py
│       third.py
│
└───validation
        input_params_validation.py

而更深層次的，程式碼架構的設計會降低程式碼的腐化速度

降低程式碼的腐化速度

通常在一個專案新起的時候，專案程式碼的可讀性，維護性都會做的很好，然而隨著專案的龐大，不同背景不同能力的開發人員的進場和離場，程式碼的可讀性和可維護性都會漸漸的變差，這個是一個專案進行過程中不可避免的，聰明的團隊通常不但會制定一系列的比如程式碼質量掃描，程式碼review等手段降低程式碼的腐化速度，還會在在需求的開發過程中安排一定資源的程式碼重構的任務，去不斷重構腐化的程式碼。
而一個好的程式碼架構，也會在一定程度上制約開發人員“生產”腐化程式碼的可能，從而降低了程式碼的腐化速度。這是因為在制定了程式碼架構之後，入場的開發人員們通常會選擇遵從程式碼架構的規則編寫程式碼，通過規則的制約，可以很好的制止一些不謹慎的程式碼的產生。
我們通過一個反例來看看，一個不好的程式碼架構會對專案的開發產生怎樣的影響。
在一個真實專案中，大家制訂了一個這樣的簡單程式碼架構：

專案程式碼使用簡單的Controller->Service->Repository->Entity分層，其中Entity層作為資料庫的對映，並且整個程式碼架構中，可以隨意傳遞entity, 甚至直接將entity傳遞出去

這樣的程式碼架構會導致以下幾個問題：

1. 沒有DTO的存在，開發人員會因為方便傾向於把entity直接丟出去作為request和response的資料對映。這樣當出現傳入引數和資料庫table設計出現不一致時，會出現很多的程式碼問題。
2. 由於並沒有任何相關的約束並且由於#1，開發人員有可能將業務邏輯相關的程式碼同時放在controller和service中。這種做法會導致controller和service層出現強耦合，並且業務邏輯被分散在程式碼的各個角落，導致很難去閱讀進一步降低可維護性。
3. 由於程式碼的事務控制是在service層做的，因為#2的原因，很多人在開發過程中並沒有一個對系統的全域性概念，直接導致了很多的業務程式碼出現了只能部分回滾資料的問題，直接導致的很多bug的出現。

由上文可以看到，一個好的程式碼架構設計對於專案的必要性。接下來將介紹在web service中，比較常使用的程式碼組織架構。