我想知道如何将具有分层结构的项目划分为应用程序。假设我正在尝试建立像github.com这样的东西。在github.com中，一个帐户有一些存储库，它们具有一些功能，如代码，问题或拉取请求。这些功能引用了其他功能。在这种情况下，哪个是应用程序，哪个不是？那时，我应该将应用程序作为子应用程序放在根目录或应用程序目录中吗？
答案 0 :(得分：3)
在理想的世界中，每个应用程序都将独立于其他应用程序，或者只与其他应用程序松散耦合。但在许多现实世界的情况下，往往存在如此相互依赖，以至于很难抽象出它们。
那么，在那种情况下......分离它们的最佳方法是将它们分成功能组，其中每个应用程序中的大多数视图，模型等仅在应用程序中使用。所以，鉴于你的github示例，“问题”可能是他们自己的应用程序。 issues应用程序将具有仅与显示，编辑和服务（ajax请求等）问题相关的特定视图，用于存储问题的模型及其持续状态，仅负责呈现问题视图的模板，问题条目例如，每个用户的问题，每个项目的问题，特定问题的详细信息。实际上有很多特定于问题的代码。
是的，当你完成时，你将拥有从那些问题模型到用户模型的外键，以及可能的提交模型，项目模型......许多相互依赖会阻止{{1在没有其他应用程序的情况下工作的应用程序。但从逻辑上讲，当需要处理问题系统的时候，你就会知道要去哪里......因为所有问题代码都在一个地方。例如，所有默认问题设置都在issues中，所有主要与问题相关的表都将以issues/settings.py为前缀，例如。 app_label，issues_issue ..等..
所以基本上，尝试在核心功能的基础上分解它，并尽量减少依赖的数量..或者至少，尽量避免循环依赖...例如，一些应用程序将有许多其他应用程序取决于它们，有些人没有。尽量避免致命的拥抱。但是，最终会发生依赖关系。
在某些情况下，您可能能够实现可选的依赖项，例如..当应用程序A，Model_A中发生某些事情时，它应该触发App B，Model_B中发生的事情..但仅在安装了App B时。有一些方法可以实现这种不太紧密耦合的行为，例如Django的信号系统
https://docs.djangoproject.com/en/2.0/ref/signals/
但这并不像外键那么可靠，所以不要随意松散地结合永远不会脱钩的东西。
尝试根据紧密耦合的功能将内容划分为应用程序，例如。与其他视图相关的视图。将您的所有应用程序所依赖的内容放入主应用程序或库中......您会发现随着代码的增长，代码更容易维护。
答案 1 :(得分：0)
我会将应用程序放在您的主项目中的manage.py文件级别，然后您可以轻松运行此命令： python manage.py startapp login_app 。然后你可以有这样的结构：
main_project
login_app
codeissues_app
pullrequests_app
答案 2 :(得分：-1)
无法为项目中的每个应用创建独立应用。我建议你关注domain driven design。 （google it）
所以想象一下，你正在建立一个电子商务商店。你会有类似的东西：
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
无论如何，这只是主题的表面。取决于您正在构建的许多项目以及有哪些要求。看一下Domain Driven Design。