我真的在为整个应用程序创意而苦苦挣扎。我阅读了很多教程和风格指南，我知道我应该尝试创建专门的应用程序，只做一件事。在查看一些简单的教程项目时，这一切都是有意义的，但一旦涉及到复杂的现实生活项目，我发现自己无法确定我应该如何在不同的应用程序之间划清界限。
其中一个问题是，我想要一个站点(或多个站点)，用户可以在其中看到很多不同的内容。遵循应用程序设计规则时，应该来自不同应用程序的内容。我怎么会意识到这样的事情？我的第一个想法是创建一个名为 ui 的应用程序，它只处理所有实际导致模板的 View ，所有其他应用程序提供模型和辅助功能。但我担心 ui 应用会变得越来越大。
举个小例子:让我想要一个网站，用户可以在其中执行以下任务:
- 选择一个主题
- 为所选主题设置一些选项
- 上传与其帐户关联的文件
- 将一些上传的文件分配给主题
- 录制一些与主题相关的音频
现在，我将创建三个应用程序:
- subjects(包含主题模型和一些相关模型)
- 资源(包含资源模型，处理上传)
- 音频(处理所有音频录制和处理内容)
但是，我需要某种 main 或 ui 应用程序来处理这些应用程序的交互方式并创建实际站点，所有应用程序都以某种方式参与其中.
那么，有什么“正确”的方法可以做到这一点吗？或者有什么模式可以使用吗？我也希望能链接到有关该主题的优质资源，尽管我已经阅读了很多。
您只需要确保您的结构对您有意义。
无需为绑定(bind)到项目逻辑另一部分的每个功能创建一个新应用。
可重复使用的应用程序完全不同，它们的代码在某种程度上应该不知道实现。
看看Django's structure寻找灵感
您的示例的可能布局:
project_root/
project/
__init__.py
settings.py
urls.py
templates/
app1/ # override stuff
static/
media/
app1/
__init__.py
admin/ # as a package
__init__.py
subjects.py
resources.py
# etc
models/ # as a package
subjects.py
resources.py
# etc
managers/
__init__.py
subjects.py
resources.py
# etc
services/
__init__.py
audio.py # upload handler etc
views/
__init__.py
subjects.py
urls/
__init__.py
subjects.py
templates/
app1/
subject_list.html # override at project level
static/
app1/
css/
subject.css # override at project level
app2/
__init__.py
models.py # holds a Member model or whatever you require
manage.py