Разделение проекта django на два больших модуля и проблемы с импортом

#python #python-3.x #django

#python #python-3.x #django

Вопрос:

Я хочу начать новый корпоративный проект, который будет очень большим и будет иметь тщательную бизнес-логику. Я хочу разделить его на два «подпроекта», один с моделями, API и бизнес-логикой (называемый «бизнес»), а другой с представлениями для веб-приложения (называемый «webapp»).

Идея отделения веб-приложения (представлений) от моделей, API и бизнес-логики заключается в том, что я хочу, чтобы эти 3 последних были сервисом как для веб-приложений, так и для мобильных устройств, а бизнес-логика очень подробная, поэтому мне нужен был специальный проект для ее обработки.

Макет выглядит следующим образом:

 project/
   business/
 |    __init__.py
 |    rest_urls.py
 |    business_app_1/
 |  |    __init__.py
 |  |    controllers.py
 |  |    models.py
 |  |    serializers.py
 |    business_app_2/
 |  |    __init__.py
 |  |    controllers.py
 |  |    models.py
 |  |    serializers.py
   project/ #this one is just the main configuration django app
 |    __init__.py
 |    settings.py
 |    urls.py
 |    wsgi.py
   webapp/
 |    __init__.py
 |    urls.py
 |    view_app_1/
 |  |     views.py
 |    view_app_2/
 |  |    views.py
 |    view_app_n/
 |  |    views.py
  

Я только что провел тест, потому что я никогда не делал такой сложный макет, и я получил ошибку импорта ( ModuleNotFoundError )

view_app_1/views.py:

 from business.business_app_1.models import BusinessModel1
print(BusinessModel1())
  

Я просто попытался запустить его из терминала, и он говорит, что нет модуля с именем «business» (все мои папки имеют init.py за исключением root, хотя я тоже пытался добавить его туда).

Есть ли какой-нибудь способ импортировать это без sys взломов модуля?

Комментарии:

1. Ваш PYTHONPATH не включает корень вашего проекта. Смотрите здесь: docs.python.org/3/install /… . В качестве альтернативы создайте .env файл в корне вашего проекта и установите его там.

2. Кстати, ваш подход к определению приложений в проекте, учитывая, что это крупное корпоративное приложение, является плохим. Я предлагаю вам прочитать о DDD и о том, как управлять границами служб для архитектуры, основанной на службах. Вы создаете будущие проблемы с текущим подходом.