sim3x, ну, я (чисто мое мнение) хорошую архитектуру вижу как-то так: entity - repository - service - controller. Entity - просто модель данных (например, представление таблицы из БД). repository - операции типа выборок, вставок и т.п., реализующие общий интерфейс. Нужно, чтобы абстрагироваться от типа хранилища. Service - собственно бизнес-логика. Ну а controllers - тут все ясно. Контроллеры, которые дергают методы сервисов. Всякие хелперы/валидаторы и т.п. я тут умышленно не озвучил.
"Скомпоновали вью и формы и назвали сервисами" - там еще это все в транзакции завернуто (опционально). На самом деле, удобная штука, потому что service layer должен выполнять проверку данных, которые в него передаются - и тут это реализовано прямо на джанговских формах. То есть не важно, из вьюхи дернул или из консольной команды или еще как-то - валидация уже есть.
"потому как так проще." - но ведь бизнес-логика может затрагивать сразу несколько моделей. В какой из моделей тогда этот метод реализовывать?
"Упростит ли ето что-то?" - даст возможность абстрагировать бизнес-логику от конкретного фреймворка, его ОРМок и т.п.. Да, я понимаю, что конкретно эта либа все равно идет вразрез с этим высказыванием из-за ее привязки к Джанго, но вообще в идеале сервисный слой должен быть независимым.
sim3x, ну это да, согласен с тем, что "Микрофреймворки на продакшене доступны на уровнях выше мидла
Джун без строгой структуры сваливается в говнокод сразу же".
А почему так уверенно: Fat models? Смешивается по сути entity с бизнес-логикой проекта. Сами файлы моделей зачастую очень сильно разрастаются. Какое архитектурное преимущество у такого подхода перед вынесением бизнес-логики в сервисы?
sim3x, то есть разработка на микрофреймворках - это обязательно велосипедостроение разве? Что конкретно из Django будет юзаться в Rest API? Думаю, что ORMка да роутинг. Может быть, что-то еще по мелочи. Первое решается прикручиванием к проекту любой ормки в виде сторонней библиотеки (алхимия - для питона, горм - для го), второе есть и так в любом микрофреймворке из коробки. Какие батарейки из джанго-комбайна делают его удобным для создания рест апи? Возможность разрабатывать быстро разве что. И то порог вхождения для новичка в любой микрофреймворк явно ниже, чем в джангу. Поэтому это тоже спорный вопрос.
Да и так ли уж в Django не будет велосипедов? Тот же насущный вопрос "где в Django хранить бизнес-логику" уже приводит к спорам и разногласиям. Кто-то во view хреначит, кто-то пилит толстые модели, а кто-то делает свой слой сервисов. Чем не велосипедостроение?
Gimir, можно. Я использую как раз Next.JS - мне норм. Как раз лучше использовать готовое решение для рендеринга, чем пилить свою балалайку для аналогичной задачи. У тебя SSR с питоном вообще никак не связан, поэтому апи пили вообще на чем угодно. Единственное, не советую Django, потому что юзать ее для обычного REST api избыточно. Я взял вообще gin/gonic (go).
P.s. "при наличии опыта пишется за несколько часов" - с тестами, без?)