Отвечая на вопрос, увы, таковой нету. Вы должны сами для себя решить и не спустя три месяца.
Но если желаете более предметно, то вот Вам мои ощущения по поводу Вашей структуры, к которой вы пришли...
Первое, что бросается в глаза - настройки. Да, Вы следуете идеологии Django, которая неявно шепчет всем нам как их компоновать: но это небезопасно. Почему в настройках у вас модули, два из которых отражает какое-то окружение (разработка, боевое и что-то общее между тем и тем)? Исходя из Вашей структуры сразу витает в воздухе вопрос: "А почему настройки боевого окружения вдруг должны быть в репозитории? А как быть с секретным ключом? А безопасно ли это?". Следующий логичный вопрос удобства: почему я, как разработчик, вдруг должен заставлять своих DevOps'ов компоновать и поддерживать за меня настройки в виде файлов (модулей)? Это ведь исполняемый файл и там бесчисленное количество возможностей; более того, это не безопасно. Сейчас бОльшая часть проектов поднимается средствами docker-compose, куберов и прочих прелестей: дико неудобно собирать и поддерживать настройки в виде файлов для каждого запускаемого контейнера (у нас ведь есть переменные окружения). Надеюсь, здесь понятен основной посыл: безопасность и удобство использования.
(здесь я не сразу понял, что это именно проект, а не приложение; подробности в комментариях)
Едем дальше - core. Почему именно такое название? Понятное дело, ядро, Django в своих исходниках делает и всё такое... Но зайдя в такой проект, сразу ли будет понятно за что отвечает это приложение? Нет. В общем-то даже в документации к Django в quick start название приложения опирается на её главную бизнес-потребность.
Переходим к следующему: папка apps с приложениями. Для начала вроде всё удобно и логично: есть ядро проекта, а есть дополнения к нему а значит их нужно как-то отделить от этого ядра. А что делать если ядро будет всегда одно в проекте? А что делать если дополнительных приложений будет всего одно? А зачем тогда ему целая папка (приложению) если само приложение - и есть папка (или модуль в нашем случае)? Так оставлять или менять уровень вложенности? На самом деле что core, что appN - являются такими же Django приложениями (одинаковыми), а значит и уровень абстракции у них - один; один уровень абстракции говорит нам о том, что и appN нужно класть где-то рядом с core (здесь должно быть другое название как и писал). Часто я вижу в проектах, что core так и остаётся одой единственной core папкой без дальнейшей расширяемости. Вывод - преждевременная оптимизация - вещь нелогичная по сути своей.
Папка template. Здесь я всегда доверяюсь Django и кладу шаблоны в папку приложения (делая ещё две папки - templates, а в ней - папку с названием приложения). Здесь, думаю, подойдёт правило класть то, что используется, ближе к тому месту, где это используется (но с поправкой на рекоммендации оф. документации Django).
Папка static. В среде отладки её быть в принципе быть не должно; обычно вся статика всегда в первую очередь связана с приложением, куда мы её и стараемся класть (как с папкой templates), что является и советом из Django документации.
Папка models. Вынося её куда-то в отличное от папки приложения место, мы сразу же забиваем на автономность самого приложения; приложение сразу же становится зависимым от внешнего кода (чего нужно избегать). Обычно каждое приложение имеет свои модели и не зависит от моделей другого приложения.
venv. Актуально только на компьютере каждого разработчика; по-моему это неудачное решение класть платформо-зависимые файлы под контроль версий.
Простой
Средний
Сложный
