James班尼特有一个关于如何在Django中组织可重用应用程序的精彩的set of slides。

我更愿意将Django应用程序视为可重用的模块或组件，而不是“应用程序”。
这帮助我封装和分离某些特性，如果我决定与整个社区共享一个特定的“应用程序”，提高了可重用性和可维护性。
我一般的做法是把特定的功能或功能集集中到“应用程序”中，就好像我要公开发布它们一样。这里最难的部分是弄清楚每个桶有多大。
我使用的一个很好的技巧是想象如果我的应用程序公开发布，它们将如何使用。这经常鼓励我缩小水桶，更清楚地定义它的“目的”。

以下是2008年9月6日的最新简报。
DjangoCon 2008: Reusable Apps @7:53
Slide: Reusable_apps.pdf的

取自幻灯片

这应该是它自己的应用程序吗？

• 这与应用程序的重点完全无关吗？
• 它和我正在做的其他事情是正交的吗？
• 我在其他网站上是否需要类似的功能？

如果有一个是“是”最好将其拆分为单独的应用程序。

我倾向于为每个逻辑上独立的模型集创建新的应用程序。例如：

• 用户配置文件
• 论坛帖子
• 博客文章

关于这个问题，我在网上找到的两个最好的答案是：
1.可重用应用程序对话（slides）（video）也在其他答案中提到。班尼特，作者和Django贡献者，定期发布应用程序供其他人使用，并对许多小应用程序有强烈的观点。

1. Doordash's Tips for Django at Scale给出了相反的建议，并说在他们的情况下，他们迁移到一个单一的应用程序后，开始与许多单独的应用程序。他们在应用程序之间的迁移依赖关系图方面遇到了问题。
   两个来源都同意在以下情况下您应该创建单独的应用程序：

• 如果你计划在另一个Django项目中重用你的应用（特别是如果你计划发布它供其他人重用）。
• 如果应用程序与另一个应用程序之间几乎没有依赖关系。在这里，你可以想象一个应用程序在未来作为自己的微服务运行。

我遵循的规则是，如果我想在不同的项目中重用功能，它应该是一个新的应用程序。
如果它需要深入理解项目中的模型，那么将它与模型结合起来可能更有凝聚力。

Andrew Godwin（Django核心开发人员）给出了这个问题的最佳答案：
在我看来，应用程序的主要目的是提供可重用组件的逻辑分离--具体来说，就是为models/admin/等提供一流的命名空间。- 并提供一种简单的方法来“打开”或“关闭”事物。
在某些方面，它是Django创建时的遗物-当时Python Package 和模块开发得很少，您基本上必须有自己的解决方案来解决问题。也就是说，它仍然是Django心智模型的核心部分，我认为INSTALLED_APPS仍然是一个比Python替代入口点更干净、更简单的解决方案（这使得禁用安装在环境中但你不想使用的包变得相当困难）。
你认为有什么特别的东西可以从今天的应用概念中分离出来吗？模型和管理员需要它来自动发现和一个独特的命名空间前缀，所以这很难撤销，我很难想象你需要它的其他功能（事实上，如果你只想要一个库，你可以把它变成一个普通的Python库-不需要应用 Package ，除非你要发布模型，模板或管理员代码IIRC）

一个“应用程序”可以是许多不同的东西，这一切都归结为品味。例如，假设你正在创建一个博客。你的应用程序可以是整个博客，或者你可以有一个“管理”应用程序，一个“网站”应用程序，一个“RSS”应用程序，一个“服务”应用程序，这样开发人员就可以以自己的方式与博客交互，等等。
我个人会让博客本身成为应用程序，并打破它的功能。这个博客可以很容易地在其他网站上重复使用。
Django的好处是它可以识别models.py目录树中任何级别的www.example.com文件，将其视为包含Django模型的文件。因此，将您的功能分解为“应用程序”本身中的较小“子应用程序”不会使任何事情变得更加困难。

根据我的理解，一个新的应用程序是一个新的功能或一组功能，可以在以后的项目中重用。功能集的大小取决于您的个人偏好，只要它不是通用的。保持“应用程序”的简洁也是一个很好的方法，可以完全控制您想要部署哪些功能，哪些功能不需要。希望这对你有帮助！