Если бы не знал автора статьи лично, то честно говоря, подумал бы что PR отдел СДЭКа заказал статью.
Но хорошо что мир не без добрых людей. До сих пор помню паренька из визового центра Великобритании в 2015, когда он после моих просьб забрал мой паспорт после уже приемки корреспонденции и закрытия ВЦ и отдал ночью того же дня (вылет был на след день утром).

Ох, я был в обоих лагерях "services vs managers". :)

Для больших проектов 100+ моделей обычно выбираю services последнее время. На практике поддерживать service, где и python логика и ORM в одном месте - легче. Да и распиливать потом - одно удовольствие. Но для маленьких проектов, как у автора - согласен, managers предпочтительнее и чище.

В любом случае вердикт один - нужно выносить из save().

Привет!

Пару советов для дальнейшего успешного поиска работы:

1. Используй сразу python poetry + Dockerfile + docker-compose. Сейчас это такие же стандарты, как знание git. Дадут тебе +15 очков на собеседовании.

2. class Tokens(models.Model) -> class Token(models.Model)

3. settings.CHARACTERS = string.ascii_letters + string.ascii_digits +5 очков

4. Вместо цикла while True с filter() query надо использовать try: Model.objects.create() / except IntegrityError - так будет в 99.9% случаев только один запрос. +30 очков

5. token.requests_count += 1 -> Models.objects.filter().update(requests_count=F("requests_count")+1) +20 очков

6. Вынести код из save() в отдельный модуль services.create_token . +15 очков

7. Можно вместо рандомайзера использовать hash от pk, но это так уже, когда совсем делать нечего :) Нашел в одном из своих старых проектов:
   hashlib.shake_128(user_id.encode("utf-8")).hexdigest(3).upper()

Из реальных минусов django admin не указан самый главный: отсутствие нормальной кастомизации.

В реальной жизни первое время встречались кейсы, когда клиент не понимал почему я сделал такую красивую админку быстро, но не могу "перекрасить всего лишь кнопку".

Теперь я говорю так: админку даю вам в подарок as-is и мы ее внешне не переделываем. Как только функционал бота будет более-менее стабилизирован, бизнес модель протестирована, то выделяем бюджет и делаем нормальную панель на FastAPI + Vue/Flutter/подставьте_свою_технологию с любым дизайном. Такой подход уже работает нормально.

Я один из тех, кто использует aiogram + django admin and migration для MVP.

По минусам в статье:

• Изначальная несовместимость фреймворков – какая разница, когда aiogram и django все равно крутится каждый в своем docker и лежит в разных репах? Они выполняет разные функции и django может быть удален одной кнопкой, когда придет время для его удаления?
  Мы же не говорим что PostgeSQL и Redis несовместимые технологии - просто выполняют разные задачи.
  Из плюсов - все написано на Python, нам не нужен frontend разработчик.

• Django ORM – У нас что, 1000 админов? Зачем нам асинхронная ORM в админке? Понятно, что пользователей бота может быть несколько десятков тысяч + сам интерфейс предполагает быстрое взаимодействие - там нужна скорость, а для админки зачем скорость?

• Из пушки по воробьям – no comments. Не нужны forms, tests, views and caches - не используй, не нужны applications - положи все в одну папку. Джанго можно использовать не только как написано в Tutorial, а просто сделать проект на 5-7 файлов в одной папке, если структура БД небольшая.

Дополнительный плюс:

• Переодические задачи – если нужно раз в час что-то обновить, то periodiq + dramatiq отлично дружат с Django ORM и так же экономит время и деньги.