да

первую часть плохо понял)

про модели: изначально я писал всю логику в моделях, и теперь, часто крутя скролл мыши в поисках нужного метода, очень жалею об этом 😃
Из-за этого, сейчас, я стремлюсь оставить моделям только роль "отражения"  таблицы в БД. Ну максимум - простые методы.

Вот мне понравилось твоя мысль про добавление финкционала работы с БД в менеджер или в queryset. Сам я часто про эти возможности забываю.

В итоге: модели и вью - максимально "худые", вся логика в сервисы. Твоя мысль заставила задуматься о других вариантах.

Это уже мы сами контролируем - модели тоже можно делить. Мы изначально каждую модель держим в отдельном файле, в init.py перечисляем. Очень редко(1 в 3 года) появлялась модель, в которой и manager, и queryset выделяли отдельно и импортировали локально, много логики фильтрации и считаемых на лету значений. Создали пакет по названию модели, импортировали там уже только модель. Так держим жесткие <300 строк на файл, с поиском по проекту проблем пока не возникало

https://www.b-list.org/weblog/2020/mar/16/no-service/
Статья от автора книг по Django для enterprise, если вкратце: создавая сервисы мы лишь зря пишем новый слой абстракции, по сути перенося логику моделей в сервисы, но не абстрагируясь от сложности работы с сущностями. Стоит изначально использовать уровни работы с сущностями самого Django, это даст такой же код, как и в сервисах, но ещё и будет лучше использовать инфраструктуру django

будет у меня большой проект в работе, тоже разобъю по файлам.
Но не тяжело ли прослеживать связи когда они в разных файлах? Я допустим не запоминаю related_name, с которыми давно не работал. приходится идти в модель и смотреть, а потом куда-нибудь еще глубже по связям(

Вот думаю буду также забывать методы в менеджерах и queryset'ах

будет у меня большой проект в работе, тоже разобъю по файлам.
Но не тяжело ли прослеживать связи когда они в разных файлах? Я допустим не запоминаю related_name, с которыми давно не работал. приходится идти в модель и смотреть, а потом куда-нибудь еще глубже по связям(

Вот думаю буду также забывать методы в менеджерах и queryset'ах

Это совсем не проблема, учитывая возможности сегодняшних иде. Можно без related_name, раз уж на то пошло.

я, как начиная в джанго, не разобрался: как, без related_name, получать доступ к моделям со сложноым именем, так и не возвращался к этому(

Это уже не проблема django, здесь надо изучать цикломатическую сложность кода, связанность объектов и какой процесс вы преследуете, строить модели относительно процесса, а не наоборот. Уменьшаете в целом сложность проекта - разбираться проще. Больше 5 app или видите что новый домен не связан со старым - создавайте новый проект, переходите к SOA

Извините за нескромность, но какой у вас опыт в разработке?

Сервисы к сожалению не решают эту проблему. Если хочется сервисную архитектуру, абстракции для DDD, стоит подумать - а зачем? Если вы в django, в случае переписывания проекта на другие фреймворки(flask, fastapi? cherrypy) переписывать придётся все равно все, гибкости и возможности оставить слой бизнес-логики не получится. Забывчивость с именами связанных объектов - бывает, но более вероятно что разработчик ознакомится с документацией django и постарается следовать вашим правилам, нежели полезет в сервисы

Подскажите, как реализовать данную заядачу :
Есть два отдельных приложения -
Джанго сайт, допустим обычная страничка с пост формой, куда можно вводить сообщение.

И телеграмм бот на аиограм.

Как реализовать передачу введенного сообщения из формы телеграмм боту, чтобы он сделал что-то такое:

for user in users.select()
   try:
       bot.send_message(user.chat_id, request.POST[‘message_from_site’])
except:
   pass


Интересует а) Каким образом передать туда это сообщение в функцию
б) как запустить функцию после отправки пост формы на сайте?

вижу 1 приемлемый вариант:
Прикрутить к боту Api (когда делал бота, мне советовали FastApi)