我准备用Django构建一个相当复杂的“产品”。在这里我将避免使用术语“项目”和“应用程序”，因为我不清楚它们在Django中的具体含义。
项目可以有很多应用程序。应用程序可以在许多项目之间共享。很好。
我不是在重塑博客或论坛——我没有看到我的产品的任何部分在任何情况下都是可重复使用的。直观地说，我将其称为“应用程序”。那么我是否将所有工作都放在一个“app”文件夹中?
如果是这样的话……在Django的项目方面。应用命名空间，我倾向于使用我的产品。我的产品，但这当然是不允许的(但我正在构建的应用程序是我的项目，而我的项目是一个应用程序!)因此，我相信也许我应该通过为每个“重要”模型构建一个应用程序来接近Django，但我不知道在我的模式中如何划分边界来将其划分为应用程序——我有很多具有相对复杂关系的模型。
我希望有一个共同的解决方案…
当前回答
一旦你学会了使用startproject和startapp，就没有什么能阻止你在同一个Python包中组合“project”和“app”了。一个项目实际上只不过是一个设置模块，而一个应用程序实际上只不过是一个模型模块——其他一切都是可选的。
对于小型网站来说，这样做是完全合理的:
site/
models.py
settings.py
tests.py
urls.py
views.py
其他回答
一旦你学会了使用startproject和startapp，就没有什么能阻止你在同一个Python包中组合“project”和“app”了。一个项目实际上只不过是一个设置模块，而一个应用程序实际上只不过是一个模型模块——其他一切都是可选的。
对于小型网站来说，这样做是完全合理的:
site/
models.py
settings.py
tests.py
urls.py
views.py
我发现下面这篇关于django应用程序和项目的博文非常有用:
http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/ http://web.archive.org/web/20080302205555/www.pointy-stick.com/blog/2007/11/09/django-tip-developing-without-projects/
原则上，使用django你有很大的自由来组织你的产品的源代码。
在这里，Django的创建者们自己指出了这种差异。 我认为考虑应用程序必须在其他项目中可重用是件好事。Django提供了现代的web应用程序，这也是一种很好的思考方式。
假设你正在创建基于JavaScript的大型动态web应用。
你可以在django中创建一个名为“FrontEnd”的应用程序——在这个应用程序中你会显示内容。
然后创建一些后端应用程序。示例应用程序命名为“评论”，将存储用户的评论。“评论”应用程序本身不会显示任何东西。它只是一个API，用于动态JS网站的AJAX请求。
这样你就可以重用你的“评论”应用程序。你可以让它开源，而不用开放整个项目的源代码。这样你就能保持清晰的项目逻辑。
为什么不让你用我的产品，我的产品?你需要做的大致包括:
django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py
等等。如果我说views。py不必叫views。py会不会有用?只要你能在python路径上命名一个函数(通常是package.package.views.function_name)，它就会被处理。就这么简单。所有这些“project”/“app”的东西都只是python包。
现在，你该怎么做?或者说，我该怎么做呢?好吧，如果你创建了一个重要的可重用功能，比如一个标记编辑器，那就是当你创建一个“顶级应用程序”时，它可能包含widget .py, fields.py, context_processors.py等——所有你可能想导入的东西。
类似地，如果你可以创建一个类似博客的东西，在安装中使用一种非常通用的格式，你可以把它包装在一个应用程序中，有自己的模板，静态内容文件夹等，并配置一个django项目的实例来使用该应用程序的内容。
没有硬性规定说您必须这样做，但这是框架的目标之一。事实上，所有的东西，包括模板，都允许你从一些共同的基础上包含，这意味着你的博客应该适合任何其他的设置，只需要照顾自己的部分。
但是，为了解决您的实际问题，是的，没有人说您不能使用顶级项目文件夹。这就是应用程序所做的，如果你真的想做，你可以做到。然而，我倾向于不这样做，原因如下:
Django's default setup doesn't do it. Often, I want to create a main app, so I create one, usually called website. However, at a later date I might want to develop original functionality just for this site. With a view to making it removable (whether or not I ever do) I tend to then create a separate directory. This also means I can drop said functionality just by unlinking that package from the config and removing the folder, rather than a complex delete the right urls from a global urls.py folder. Very often, even when I want to make something independent, it needs somewhere to live whilst I look after it / make it independent. Basically the above case, but for stuff I do intend to make generic. My top level folder often contains a few other things, including but not limited to wsgi scripts, sql scripts etc. django's management extensions rely on subdirectories. So it makes sense to name packages appropriately.
简而言之，有一个约定的原因和任何其他约定是一样的——当涉及到其他人处理您的项目时，它会有所帮助。如果我看到fields.py，我立即期望它的代码子类django的字段，而如果我看到inputtypes.py，我可能不清楚这意味着没有看它。
试着回答问题:“我的 应用程序做了什么?”。如果你不能回答 用一句话，也许你可以 用cleaner把它分成几个应用程序 逻辑。
在我开始使用django后不久，我在某个地方读到了这个想法，我发现我经常问自己这个问题，这对我很有帮助。
你的应用程序不必是可重用的，它们可以相互依赖，但它们应该做一件事。
