基于相同后端逻辑的多个站点的Django项目的最佳结构是什么？
我已经开始研究一个新的大型项目 - 许多基于城市的网上商店，每个网站都在一个域的子域上工作，例如citydomain.webshop.com。这些网站中约有40个开始同时运行。基于相同后端逻辑的多个站点的Django项目的最佳结构是什么？
项目的后端业务逻辑和模板样式在每个站点上都是相同的。一些静态文件和数据库数据在所有站点和特定站点（日志，图像，销售物品，订单等）中都是通用的。
我的问题是如何实现最佳可能的体系结构，以便某个用户访问不同子域上的相同URL将获得由相同后端逻辑处理的子域的特定数据。
我认为可能的架构以下选项：
1）Django项目实例：为每个站点的所有站点或许多情况下，一个实例？
就DRY原理而言，第一种方式似乎比第二种方式合乎逻辑。我认为，最好应该有一个项目实例与子域名为每个站点的具体图片，日志的名字很多subfoolders等
2）数据库：一是分贝为每个站点的所有站点或多个数据库？
由于DRY原理相同，我倾向于拥有ONE数据库。大量的数据将在不同的特定于站点的数据库中重复使用，并且它们之间的即时切换可能会很麻烦（根据文档，数据库路由器似乎是这里的工具）。
只有一个数据库，我应该使用sites framework在各种表中存储特定于站点的数据（据我所知，外键为Site模型）？ 那么应该如何根据当前的子域更改SITE_ID？ 我应该使用： a）一些自定义中间件或 b）一些插件，如django-subdomains,django-multisite,Airavata？
或者根本没有用处sites framework？
3）设置：在settings.py文件（主之一，许多站点特定的那些店设置）或组合主要settings.py文件只（也许内Site表或另一个表存储在数据库中的特定站点选项会延长它）？
4）虚拟主机：一个仅用于主域或者每个站点有多个虚拟主机？ 第二个选项可以用许多小型站点特定的settings.py文件与其自己的SITE_ID（从一个主要的settings.py继承）与每个子域的许多站点特定的WSGI文件粘在一起建立？
请给我一些关于上述项目最佳实践的建议。对于这些“十字路口”式选项中的每一个应该是什么样的正确决策，你会推荐什么？
好吧，我会在一堆工作后回答我自己的问题。
根据我的项目需要，我决定将几乎所有东西都集中在一个地方，不要以后再与同样东西的很多版本混淆。 一个项目实例，一个数据库，一个设置包，一个虚拟主机。
子域特定的数据存储在数据库中（链接到自定义写入的域模型），如果是纯文本数据b）或作为文件保存到项目实例中的某个特定于子域的目录树，如果它是二进制数据（大部分图像）。
设置包由基本设置文件和三个特定于环境的文件（开发，分段，制作）组成，这些文件从这一个基本文件导入所有内容。您必须选择要使用的文件并将其重命名为settings.py。