> **核心要点：**  
> - Django App 不仅仅是文件夹划分  
> - 它不是部署单元，而是**业务领域划分单元**  
> - 在[[DRF]]中，它像按API功能划分的模块一样运作，优势显而易见  
> - 在普通的Django Web应用中，一开始可能感觉不到其必要性  
> - 但随着项目规模的扩大，在模型、Admin、测试和迁移管理方面的差异会越来越明显  
> - 设计良好的App将来可以迁移到其他项目，成为**可复用资产**  


即使[[Django]]项目部署在一个服务器上，也可以通过`startapp`命令创建多个App。
在基于DRF的无头API服务器中，这种结构尤其自然，但在基于模板的Django Web应用中，App划分也仍然有意义。


![Django项目结构概念图](/media/whitedec/blog_img/fc8aa3e622234c4689779c58a2b8b32e.webp)


## DRF中App划分如此适合的原因 {#sec-f9d183702e4a}

* API边界清晰

  * `accounts`
  * `posts`
  * `billing`
  * `notifications`

* 每个App都像独立的API集合一样运作

  * models
  * serializers
  * views / viewsets
  * permissions
  * urls
  * tests

* 在一个DRF服务器内，可以通过标准方式扩展多种功能

* 不同App在同一个项目中也能产生意想不到的协同效应

  * 发布文章 → 生成通知
  * 支付状态 → 用户权限变更
  * 用户设置 → 内容显示方式变更

## 普通Django Web应用中的疑问 {#sec-5b615e36b016}

在基于模板的Django Web应用中，即使划分了App，最终也会：

* 在同一个服务器上运行
* 使用同一个数据库
* 共享同一个settings
* 作为同一个部署单元绑定
* 模板流程也容易相互混淆

因此，在小型Web应用中，可能会产生“真的有必要划分App吗？”的想法。

## 尽管如此，划分App的原因 {#sec-ba9a6a819246}

* 防止模型变得过于庞大
* Admin界面按领域整理
* 迁移历史按App划分
* 更容易测试特定App
* 有助于规范导入结构，防止出现意大利面条式代码
* 未来分离功能或将其API化时，边界已然存在

## App可以成为可复用组件 {#sec-0f9d2f3a0f0a}

Django的App结构使得功能可以像**即插即用组件**一样创建。

即使是在项目内部创建的App，如果结构设计得好，将来也更容易迁移到其他项目。

例如：

* 通知功能 → `notifications`
* 标签功能 → `tags`
* 支付功能 → `billing`

如果将这些App独立创建，在下一个项目中可以像这样复用：

* 复制App文件夹
* 添加到`INSTALLED_APPS`
* 连接所需的URL
* 执行迁移
* 只需根据项目调整模板或设置

Django生态系统中著名的库也以这种方式提供。

* `django-allauth` : 以App形式提供注册、登录、社交登录功能

* `django-taggit` : 以可复用App形式提供标签功能

* `django-tailwind` : 将Tailwind开发环境以App形式集成到Django项目中

换句话说，Django App不仅仅是“我项目中的文件夹”，如果设计得好，它还可以成为在其他项目中也能复用的**功能资产**。


## 良好的划分标准 {#sec-638181ef3b61}

可考虑划分App的信号：

* 拥有独立的数据模型
* 需要独立的Admin组
* 拥有自身的业务逻辑
* 希望独立运行测试
* 未来有可能作为API或独立服务分离
* 功能名称能用服务领域来描述
* 在其他项目中也有复用的可能性

例如：

* `accounts`
* `billing`
* `notifications`
* `support`
* `analytics`


## 结论 {#sec-85c066cfb297}

在[[Django]]项目中，App的划分是

> 当项目规模扩大时，以人类可理解的单位来封装复杂性的结构

更进一步来说，它是：

> 一种将可重复使用的功能资产化的Django式模块系统

在[[DRF]]中，这一优势与API边界高度契合，因此表现得尤为明显，
而在普通的Django Web应用中，其价值则往往在项目规模扩大或开始创建多个项目时才逐渐显现。