经典ASP，我们现在正在开发一个相对较大的Django应用程序。我们试图弄清楚如何将这个项目的代码分成可管理的部分。
为了便于讨论，假设我们有客户端，它们与用户具有多对多关系，这些用户有一个角色，每个角色与权限具有多对多关系。
目前，我们将所有这些放在一个应用程序中，称为"后台"。
缺点是我们在后台应用程序中的 forms.py 和 views.py 包含所有这些实体的类。由于应用程序肯定会增长，因此我们希望将这些实体的代码分成几个文件。因此，即使它们不是真正独立的应用程序（我认为），它们肯定正在处理我们项目的后台部分的不同部分。
我在网上读过，似乎有两种情绪;一种是拆分 models.py 和 views.py 等，并将它们制作成文件夹/模块。在这些文件夹中，我们可以有一个 clients.py/users.py/roles.py 等。这将使应用程序保持完整，但分离代码。最后，我们将拥有一个包含大量文件的大型应用程序。
另一种选择是拆分代码并将客户端、用户和角色转换为单独的应用程序，并完全删除我们现在拥有的"后台"应用程序。Django 鼓励划分为更小的应用程序，但这些并不是真正的独立应用程序，客户端用户和角色密切相关，我们正在创建的维护工具反映了这一点。
我实际上是从在"后台"应用程序中创建较小的（子）应用程序开始的，但我在这里发现这是不行的。
问题是，应用程序应该鼓励重用，我们正在构建的大型Web应用程序有很多部分相互交织并相互依赖。没有真正的方法可以将其分成具有现实意义的较小可重用部分。
所以真正的问题是;在这个例子中，分离用户/客户端/角色的代码的可取方法是什么，这两种方法的优点/缺点是什么？也许甚至还有一种完全不同的方法，我们还没有找到......
谢谢你的时间。
始终使用单独的应用程序。 细分 models.py 等是一种黑客攻击，并且与您期望的黑客一样有效。您将花费过多的时间来修复接线。
不过，小型独立应用程序的主要优点是可重用性。实际上，您甚至不必将它们作为项目的一部分。事实上，我建议你不要。相反，您可以单独打包每个部分，并像安装任何其他第三方应用程序一样安装它们，只需在INSTALLED_APPS中引用它们即可。这样，您的项目只关注项目的独特之处，以后您可以将它们放入其他项目中。这也有一个附带的好处，即强制您编写自包含代码并减少对各个部分和项目的依赖。
FWIW，不过，你描述的大部分功能已经融入了Django的auth contrib包中。尚未烘焙的内容已经作为第三方软件包提供，因此无论如何您实际上只是在这里旋转轮子。
我会考虑将每个分离到自己的应用程序中。 应用结构可能会产生误导。 尽管有许多可恢复/可插拔的 django 应用程序，但许多项目并没有尝试重新打包他们的每个应用程序以供重用。 应用程序只是提供了一个很好的代码分离。
我会想象一个Role有一个模型。 可能具有特定于角色的实用程序功能，如果它是面向外部的，则可能会具有特定于滚动的URL。
这些可能是基本的 crud 操作。
/roles/add，/roles/delete /roles/create，/roles/update/这些中的每一个都可以保证自己的应用程序和 urls.py。 如果客户端具有相同的操作，则它们实际上不应该位于同一视图中。
这个问题可以在同一应用程序中通过多个视图来解决，但我认为这没有适当地利用应用程序结构。