在项目的开始阶段，一件必不可少的的事情就是就是确定代码的分层和架构。该分层和架构在一定程度上决定了未来整个项目的代码风格和维护性，对于项目的长期维护，代码架构的设计是一件非常重要的事情。
在介绍代码架构的设计之前，首先我们先谈论下为什么代码架构的设计师是一件非常重要的事情。
为什么要有代码架构
简单来讲，代码架构是为了提供更好的可读性和可维护性。
提高可读性和可维护性
大家可能还记得刚开始写代码的时候，所有的代码都会集中在一个文件，甚至一个函数中，比如：
# 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中，比较常使用的代码组织架构。
