我想知道如何将具有分层结构的项目划分为应用程序。假设我正在尝试构建类似 github.com 的东西。
在 github.com 中，帐户具有一些存储库，这些存储库具有代码、问题或拉取请求等一些功能。这些功能具有对其他功能的引用。在这种情况下，哪个是应用程序，哪个不是？这时，我应该把应用程序放在根目录下还是放在应用程序目录中作为子应用程序？
在理想世界中，每个应用程序都独立于其他应用程序，或者仅与其他应用程序松散耦合。 但在许多现实世界中，通常存在如此相互依赖的关系，以至于几乎不值得尝试抽象它们。
因此，在这种情况下，将它们分开的最佳方法是将它们划分为功能组，其中每个应用程序中的大多数视图，模型等仅在应用程序中使用。 因此，鉴于您的github示例，"问题"可能是他们自己的应用程序。issues应用程序将具有仅与显示、编辑和提供(ajax 请求等)问题相关的特定视图、用于存储问题及其持续状态的模型、专门负责呈现问题视图的模板、问题条目，例如，每个用户的问题、每个项目的问题、特定问题的详细信息。 实际上有很多特定于问题的代码。
是的，当你完成时，你会有外键，例如从这些问题模型到用户模型，也许还有一个提交模型，一个项目模型......许多相互依赖关系会阻止issues应用程序在没有其他应用程序的情况下工作。 但从逻辑上讲，当需要处理问题系统时，你会知道该去哪里。因为所有问题代码都在一个地方。 所有默认问题设置都在issues/settings.py例如，所有主要与问题相关的表都将以app_label为前缀，例如。issues_issue，issues_comment..等。。
所以基本上，尝试在核心功能的基础上分解它，并尽量减少依赖的数量......或者至少，尽量避免循环依赖......例如，一些应用程序将有许多其他应用程序依赖于它们，有些应用程序将没有。 尽量避免致命的拥抱。 但是，最终，依赖关系会发生。
在某些情况下，您可能能够实现可选的依赖项，例如，当应用程序 A 中发生某些事情时，Model_A，它应该触发应用程序 B 中发生的事情，Model_B......但前提是安装了应用程序 B。 有一些方法可以做到这种不太紧密耦合的行为，比如Django的信号系统
https://docs.djangoproject.com/en/2.0/ref/signals/
但这不如外键可靠，所以不要特意松散地耦合永远不会解耦的东西。
尝试根据紧密耦合的功能将事物划分为应用程序，例如与其他视图相关的视图。 将所有应用程序所依赖的内容放入主应用程序或库中。你会发现你的代码随着增长而更容易维护。
我会将应用程序放在主项目中 manage.py 文件的级别，然后您可以轻松运行以下命令：python manage.py startapp login_app。然后你可以有一个这样的结构：
main_project
login_app
codeissues_app
pullrequests_app
无法为项目中的每个应用创建独立的应用。我建议你遵循domain driven design.(谷歌它)
因此，想象一下您正在建立一个电子商务商店。你会有这样的东西：
your_project_folder
docs
readme
static
your_project
domain # here you put the models logic
cart
products
payment
shipping
tax
infrastructure # your packages to interface with other services
paypal
stripe
interface
rest
another_rest
presentation
public_site
...
这只是如何划分项目的一个例子。比你必须有边界。在域文件夹中，必须对包进行分组(并因此设计模型)以不允许交叉引用。
接口、基础结构和演示可以访问域。
域应该更严格。 看看这里： https://martinfowler.com/bliki/BoundedContext.html
无论如何，这只是主题的表面。这在很大程度上取决于您正在构建的项目类型以及要求是什么。看看领域驱动设计。