前言

在互联网行业中，关于业务还是技术，多多少少有些争论。认为技术大于业务的极客们认为，唯有技术才是立家之本，技术的进步可以实现更多业务迭代。而认为业务大于技术的实干家则认为业务是推动技术进步的源泉，而技术服务于业务，唯有解决业务问题才能发挥技术的价值。且不论哪种思想更有说服力，如今的互联网行业业务和技术缺一不可相辅相成是既定事实，而作为开发者的我们，唯有在业务中不断积累技术，用技术实现业务创新才是推动自身成长的正途。

python由于其语法简单精炼，学习成本低，开发周期短，如今已然从一门脚本语言往工程化的方向发展，收到越来越多的互联网公司，尤其是创业公司的追捧。但其动态语言的一些特性仍然使其在实际业务的开发中产生一些问题，尤其是大型项目的中后期，如果开发不当，会造成比较严重的代码灾难。接下来的几篇文章将提供一种用python来写业务的正确姿势，以尽量克服python在大型项目中的各种缺陷。

项目结构

作为业务代码，一个完整的项目经常包括以下几部分：

• API层: 解析请求参数，屏蔽无效参数，调用逻辑层，组装相应并返回。
• 业务逻辑层: 业务逻辑的抽象层(可以简单理解为写if和for的地方)，处理会产生结果的业务。
• 查询逻辑层: 处理单纯的查询业务，所有逻辑不会对数据产生影响。(可简单理解为GET请求后对应的部分)
• 数据层: 负责处理数据的组装（如将DB对象翻译为字典，以及整合不同），直接操作DB层。
• DB层: 一般为ORM，处理与数据库的映射。
• 外部调用层: 封装调用外部业务的http或rpc请求，供逻辑层调用。
• 配置项: 一般为app、消息队列和外部调用的一系列配置。
• 脚本层: crontab或workflow的任务脚本，不供其他类调用，可调用数据层。
• 工具类: 一些翻译类或组装类，供API层和逻辑层调用。
• 消息层: 处理消息队列的消息，可调用数据层。
• 文档
• 单元测试

基于上述部分，你的项目代码应包含以下结构(省略了各目录下细分结构)：

|____my_project
| |____api
| |____conf
| |____data
| |____doc
| |____domain
| |____message
| |____models
| |____query
| |____rpc
| |____scripts
| |____test
| |____util
|______init__.py
|____app.py
|____settings.py

如果是第一次开始一个项目工程，则需要谨慎考虑工程中这些抽象层的功能和调用逻辑，展开来说，就是每一个抽象层只能含有对应功能的代码，每一个抽象层只能调用特定的抽象层，并被特定的抽象层调用。有了清晰的层次结构，即使参与者的代码功底较差，也不至于使工程成为灾难而无从下手。笔者认为这是避免你的项目成为一锅粥的最有效的手段。

关于调用逻辑，这里举个例子，一个api如果想访问DB层的数据，那它的调用关系应该是这样的：
API层 -> 业务/查询逻辑层 -> 数据层 -> DB层
DB层只能被数据层调用，其他抽象层不能越过数据层直接对DB进行操作。

在项目不断扩展壮大的过程中，应坚决遵循期初设计的调用逻辑和功能抽象，以维持项目的层次结构。

如果是在中途接手项目，则应理清项目的调用逻辑和功能设计，尊重并遵循设计者的层次结构。

在处理一个需求前，应首先拆分需求，考虑需求需要对项目中的哪些抽象层进行修改，并着手考虑代码设计。这样，再复杂的需求经过拆分，也将变得层次分明。你的项目代码的易读性和可维护性也不会随着业务的扩大而变得很糟。

tips

当然，如果你想寻求相对靠谱且通用性强的项目结构模板，这里有一款开源项目不错。cookiecutter document