在項目的開始階段，一件必不可少的的事情就是就是確定代碼的分層和架構。該分層和架構在一定程度上決定了未來整個項目的代碼風格和維護性，對于項目的長期維護，代碼架構的設計是一件非常重要的事情。
在介紹代碼架構的設計之前，首先我們先談論下為什么代碼架構的設計師是一件非常重要的事情。
為什么要有代碼架構
簡單來講，代碼架構是為了提供更好的可讀性和可維護性。
提高可讀性和可維護性
大家可能還記得剛開始寫代碼的時候，所有的代碼都會集中在一個文件，甚至一個函數中，比如：
# 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等手段降低代碼的腐化速度，還會在在需求的開發過程中安排一定資源的代碼重構的任務，去不斷重構腐化的代碼。
而一個好的代碼架構，也會在一定程度上制約開發人員“生產”腐化代碼的可能，從而降低了代碼的腐化速度。這是因為在制定了代碼架構之后，入場的開發人員們通常會選擇遵從代碼架構的規則編寫代碼，通過規則的制約，可以很好的制止一些不謹慎的代碼的產生。
我們通過一個反例來看看，一個不好的代碼架構會對項目的開發產生怎樣的影響。
在一個真實項目中，大家制訂了一個這樣的簡單代碼架構：
這樣的代碼架構會導致以下幾個問題：
- 沒有DTO的存在，開發人員會因為方便傾向于把entity直接丟出去作為request和response的數據映射。這樣當出現傳入參數和數據庫table設計出現不一致時，會出現很多的代碼問題。
- 由于并沒有任何相關的約束并且由于#1，開發人員有可能將業務邏輯相關的代碼同時放在controller和service中。這種做法會導致controller和service層出現強耦合，并且業務邏輯被分散在代碼的各個角落，導致很難去閱讀進一步降低可維護性。
- 由于代碼的事務控制是在service層做的，因為#2的原因，很多人在開發過程中并沒有一個對系統的全局概念，直接導致了很多的業務代碼出現了只能部分回滾數據的問題，直接導致的很多bug的出現。
由上文可以看到，一個好的代碼架構設計對于項目的必要性。接下來將介紹在web service中，比較常使用的代碼組織架構。
