我的 Django Rapid Architecture 简要概述

Source: Dev.to

前几天，我在 Reddit 上看到一个针对 Django 项目的架构提案，叫做 Django Rapid Architecture。这是一份简短的文档，包含了一些指南和原则。我非常喜欢 Django，并且认为 Django 是你应该使用的最佳工具之一，于是我阅读了它并为你做了总结。

Django Rapid Architecture 是一套精选的模式和惯用法，旨在创建可维护的 Django 代码库。作者声称它来源于 15 年以上的经验和 100 多个生产项目。

Django 默认架构有什么问题？

根据作者的说法，Django 的 apps 旨在用于可复用的组件，而不是用于项目特定的业务逻辑。将所有代码都强行放入 apps 会导致灵活性不足：

• 迁移 会使早期的边界决策不可逆，从而限制了动态项目所需的灵活重构。
• Apps 倾向于 垂直封装，按功能将视图和模型分组。对于具有相互关联业务领域和接口的真实系统来说，这并不理想。

如何按照 Django Rapid Architecture 构建项目结构

而不是使用 Django 的默认范式，按 层 来组织：

1. 数据层 – 模型 & 迁移
2. 接口层 – HTTP 视图、管理命令等
3. 业务逻辑层 – 读取器 & 动作（与模型分离）

记住: Django 是一个单体应用。

文件结构示例

以下是遵循所提方法的典型布局：

project/
├── actions
│   └── some_domain.py
├── data
│   ├── migrations
│   │   └── 0001_initial.py
│   └── models
│       └── some_model.py
├── interfaces
│   ├── management_commands
│   │   └── management
│   │       └── commands
│   │           └── some_management_command.py
│   └── http
│       ├── api
│       │   ├── urls.py
│       │   └── views.py
│       └── urls.py
├── readers
│   └── some_domain.py
├── settings.py
└── wsgi.py

关键思想是将代码划分为 actions、data、interfaces 和 readers。

Source: …

Django 快速架构中的层次

如何处理数据？

模型该怎么做？

• 将 所有 模型放入一个名为 data 的单独 app 中。
• 避免超大、复杂且包含大量方法的模型；将复杂逻辑放在模型之外。
• 除了 Django 的 Model 基类外，避免使用继承，这样任何开发者都能快速理解模型的用途。

那业务逻辑呢？

业务逻辑代码应放在普通函数中，这些函数拥有明确的接口，操作模型实例、查询集或普通值。除非绝对必要，避免使用复杂的继承、mixins、装饰器或自定义管理器。

如何处理读取器？

返回 Django 响应涉及三个关键部分：

1. 查询 – 在视图中使用查询集构建；决定要从数据库获取哪些行/列，并应用过滤、关联和优化。部分逻辑可以放在自定义查询集中。
2. 值 – 要发送的数据。基础值来自模型字段；复杂业务逻辑通常放在模型方法中（例如 get_absolute_url），将原始数据转换为可用的值。
3. 投影 – 为客户端最终塑形数据。对于 JSON API，这一步是序列化为 dict/list；对于 HTML，则是模板渲染。两者都使用第 2 步得到的值。

读取器中的函数类型

原始资料提供了许多示例，但主要类别如下：

• 查询集函数 – 封装查询集的构造；使用组合和高阶函数。
• 生产者函数 – 接收模型实例并返回派生值。
• 投影函数 – 基于生产者构建；返回一个字典，将字段名映射到生成的值。

TL;DR – Django 快速架构倡导在单一的单体 Django 项目中采用 横向、层级化 的布局（data | readers | actions | interfaces），保持模型简洁，业务逻辑放在普通函数中，并通过分层来简化维护和重构。

概览

操作

REST APIs 复杂且不统一。因此，我们应该忘掉所有次要的 HTTP 动词，只使用 POST 和 GET。

单个 URL 应映射到单个视图，该视图仅响应 GET 或 POST，而不是两者兼有。这呼应了此处所描述的 RPC/gRPC 范式。

接口

使用 Django 的服务器端渲染 (SSR)

在服务器上生成 HTML 而不是使用 React 的 API 可以提升生产力。
推荐使用 HTMX 与 Django 的组合（参考链接），文章甚至认为这种方式优于使用 React。

嵌套接口以避免复杂性

组织代码时应模仿 URL 段的层级结构：

project/interfaces/http/urls.py
project/interfaces/http/api/urls.py
project/interfaces/http/api/admin/urls.py
project/interfaces/http/api/admin/widgets/urls.py
project/interfaces/http/api/admin/widgets/views.py

管理命令

Django 管理命令 也是一种接口，应该像视图一样进行处理。

哪里可以进一步了解 Django Rapid Architecture？

本文仅概述了主要思想。若想深入了解 Django Rapid Architecture 的提案，请阅读原始来源：

• 官方站点：（原文中未提供链接）

文档简短——只有几页——但包含了更多示例以及对设计决策的说明。