我想知道如何将具有层次结构的项目划分为应用程序。假设我正在尝试构建类似 github.com 的东西。
在 github.com 中，一个帐户有一些存储库，这些存储库具有一些功能，例如代码、问题或拉取请求。并且这些特征引用了其他特征。在这种情况下，哪个是应用程序，哪个不是？那个时候，我应该把应用放在根目录下，还是放在一个应用目录下作为子应用？
【问题讨论】：
标签： django django-apps django-project-architect
在理想情况下，每个应用程序都将独立于其他应用程序，或者仅与其他应用程序松散耦合。但在许多现实世界的情况下，往往存在如此相互依赖，以至于几乎不值得尝试将它们抽象出来。
那么，在这种情况下.. 将它们分开的最佳方法是将它们划分为功能组，其中每个应用程序中的大多数视图、模型等仅在应用程序内使用。因此，鉴于您的 github 示例，“问题”可能是他们自己的应用程序。 issues 应用程序将具有仅与显示、编辑和服务（ajax 请求等）问题相关的特定视图、用于存储问题及其持续状态的模型、单独负责呈现问题视图的模板、例如问题条目，每个用户的问题，每个项目的问题，特定问题的详细信息。实际上有很多特定于问题的代码。
是的，当您完成时，您将拥有例如从这些问题模型到用户模型以及提交模型、项目模型的外键。许多相互依赖关系会阻止 issues应用程序在没有其他应用程序存在的情况下工作。但从逻辑上讲，当需要处理问题系统时，您会知道该去哪里......因为所有问题代码都在一个地方。所有默认问题设置都在issues/settings.py 中，例如，所有主要与问题相关的表都将以app_label 为前缀，例如。 issues_issue, issues_comment.. 等等..
所以基本上，尽量在核心功能的基础上分解它，并尽量减少依赖的数量。或者至少，尽量避免循环依赖。例如，一些应用程序会有许多其他应用程序依赖于它们，有些人没有。尽量避免致命的拥抱。但是，最终会发生依赖关系。
在某些情况下，您可能能够实现可选依赖项，例如.. 当 App A、Model_A 中发生某些事情时，它应该触发 App B、Model_B 中发生的事情……但前提是 App 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
...
这只是您如何划分项目的一个示例。比你必须有界限。在域文件夹中，您必须对包进行分组（并因此设计您的模型）以不允许交叉引用。
Interface、Infrastructure 和 Presentation 可以访问域。
域应该更严格。看看这里：https://martinfowler.com/bliki/BoundedContext.html
无论如何，这只是主题的表面。很大程度上取决于您正在构建什么样的项目以及有什么要求。看看领域驱动设计。
【讨论】：