如何将django项目划分为应用程序

我想知道如何将具有层次结构的项目划分为应用程序。假设我正在尝试构建类似 github.com 的东西。

在 github.com 中，一个帐户有一些存储库，其中包含一些功能，例如代码、问题或拉取请求。这些功能引用了其他功能。在这种情况下，哪个是应用程序，哪个不是？那我应该把应用程序放在根目录下还是作为子应用程序放在一个应用程序目录下呢？

在理想的世界中，每个应用程序都将独立于其他应用程序，或者仅与其他应用程序松散耦合。但在许多现实世界的情况下，往往存在如此相互依赖的情况，以至于几乎不值得尝试将它们抽象化。

因此，在这种情况下......将它们分开的最佳方法是将它们划分为功能组，其中每个应用程序中的大多数视图、模型等仅在应用程序内使用。因此，考虑到您的 github 示例，“问题”可能是他们自己的应用程序。这issues应用程序将具有仅与显示、编辑和服务（ajax 请求等）问题相关的特定视图、用于存储问题及其持续状态的模型、仅负责呈现问题视图的模板、问题条目（例如，每个用户的问题） 、每个项目的问题、特定问题的详细信息。实际上有很多特定于问题的代码。

是的，当你完成时，你将拥有从这些问题模型到用户模型的外键，也许还有一个提交模型、一个项目模型……许多相互依赖关系会阻止issues应用程序在没有其他应用程序存在的情况下工作。但从逻辑上讲，当需要处理问题系统时，您会知道该去哪里..因为所有问题代码都在一个地方。所有默认问题设置都在issues/settings.py例如，所有主要与问题相关的表都将带有前缀app_label eg. issues_issue, issues_comment.. etc..

所以基本上，尝试在核心功能的基础上分解它，并最小化依赖项的数量..或者至少，尝试避免循环依赖项..例如，某些应用程序将有许多其他应用程序依赖于它们，有些应用程序将有没有任何。尽量避免致命的拥抱。但最终，依赖关系将会发生。

在某些情况下，您可能能够实现可选的依赖关系，例如......当应用程序 A、Model_A 中发生某些情况时，它应该触发应用程序 B、Model_B 中发生的情况......但前提是安装了应用程序 B。有一些方法可以实现这种不太紧密耦合的行为，例如 Django 的信号系统

https://docs.djangoproject.com/en/2.0/ref/signals/ https://docs.djangoproject.com/en/2.0/ref/signals/

但这不像外键那么可靠，因此不要特意松散地耦合永远不会解耦的事物。

尝试根据紧密耦合的功能将事物划分为应用程序，例如。与其他视图相关的视图。将所有应用程序所依赖的东西放入主应用程序或库中......您会发现随着代码的增长，它更容易维护。