我注意到有很多关于“app”在Django中意味着什么的混淆，这在很大程度上归功于文档只是用更多抽象来解释这个抽象概念。 （http://docs.djangoproject.com/en/dev/intro/tutorial01/）
哪些具体的例子应该转化为应用程序？
答案 0 :(得分：1)
我认为Django“app”是网站的高级功能。假设有一个网站提供论坛，生活聊天，常见问题解答和图片库。我会为这4个功能中的每一个创建一个单独的Django应用程序。每个应用程序都可以拥有，但不一定需要拥有自己的模型，视图，模板（以及可能的中间件和其他东西），它们都是密切相关的，并且可以用于单一的高级目的。
我就是这样解释的。
答案 1 :(得分：0)
整个django.contrib。有关每个应用的功能的说明，请参阅http://docs.djangoproject.com/en/dev/ref/contrib/。
基本上任何可以归结为独立于项目的实用程序的功能集应该成为可重用的应用程序。
答案 2 :(得分：0)
我目前正在使用Python / Django构建分布式应用程序。任何特定的服务器都需要引用一组核心功能，以及针对其情况的特定功能。有些部分需要完整的模型 - 视图 - 模板系统，其他部分只需要共享模型。应用程序的一部分将使用内存数据库，而应用程序的其余部分使用企业级数据库。
我选择将此应用程序构建为一组“应用程序”，可以使用“智能”settings.py和urls.py脚本打开或关闭这些应用程序。 “核心”应用程序将只具有整个应用程序通用的模型（但没有视图或模板）。 “webcore”应用程序将添加在提供Web UI的所有应用程序中通用的视图和模板。其他应用程序将拥有自己的模型，以及适当的视图和模板。有些应用只会实现后台服务，因此不需要视图或模板。
通过组合settings.py和urls.py脚本中的多个应用程序，我可以构建和测试应用程序的一小部分，而无需处理整个应用程序的复杂性。我还可以将部分应用程序分发到多个服务器（用于扩展或利用独特的资源）。如果我使用单个“app”构建此应用程序，我将失去很大的灵活性。
答案 3 :(得分：0)
James Bennett的talk应该回答你的所有问题：）