Executando verificação de segurança...
3

Olá, espero que esteja bem!
Antes de responder as suas perguntas eu gostaria de te parabenizar, está indo na direção certa levantando essas questões, e é bom ver que ainda tem pessoas interessadas nisto. A algum tempo eu mesmo levantei algumas perguntas muito parecidas com as suas e só fui respondê-las depois de testar e aprender vários frameworks.

Bom, vamos às respostas (numerando exatamente como você fez na sua pergunta):

1 - Existia até uma piada nos fóruns e discussões do DJango a uns anos atrás que dizia que o framework era baseado na arquitetura MVW (Model View Watherever, ou, Model View "qualquer-coisa"), de tanto que essa discussão era disseminada. À alguns anos o próprio DJango se posicionou e declarou o MVT (Model View Template) como sendo seu oficial. Desde então as documentações e padrões recomendam seguir este modelo, mas claro, por se tratar de Python você pode organizar e gerir seu projeto como preferir, eu geralmente crio uma camada de controle para validar as regras de negócio (usando classes e pacotes python), mas isso vai depender muito do seu projeto e da forma que você está acostumado a trabalhar. E sim, realmente você está certo, o DJango faz algumas coisas que combinam muito mais com um MVC.

2 - Como eu disse, é meio aberto a forma como você vai estruturar o seu código, mas a única recomendação que eu daria seria a de usar classes e pacotes python para evitar problemas futuros, o DJango funciona muito bem com eles. Sendo assim você pode criar uma camada de validação, uma de middlewares, uma de controllers...sem problemas, desde que faça sentido para você.

3 - O DJango vai aceitar basicamente qualquer arquitetura que você quiser encaixar, desde que consiga implementar na estrutura dele tudo bem. Quanto ao ServiceResult, que você mencionou, certamente faria sentido implementar algo semelhante em Python, se você achar que isso torna seu código mais limpo e fácil de entender, mas até onde sei não existe um equivalente pronto.

4 - A própria documentação do DJango cita:
Django aims to follow Python’s “batteries included” philosophy. It ships with a variety of extra, optional tools that solve common web development problems

Isso quer dizer que na maior parte das vezes o dependency injection não é necessário no DJango, já que ele busca resolver a maior parte dos problemas "de fábrica". Porém, como tudo no python, se você sentir a necessidade de fazê-lo para atender uma arquitetura mais limpa e organizada no projeto, é possível também!

5 - Sobre tipagem posso falar por mim, a algum tempo abandonei o DJango para trabalhar com outros frameworks (FastAPI principalmente), e não consigo mais deixar de usar a parte tipada do Python, claro que isso vai depender da pessoa, mas no geral eu encontrei muito menos problemas fazendo uso disso. Sem contar é claro que a maior parte dos frameworks web python está fazendo uso disso para validar os dados de entrada e saída em algum nível. Eu recomendo, mas sei que no DJango o mais perto disso são os tipos de campos dos models, que não chegam a ser exatamente uma tipagem python.

No contexto geral eu te incentivo a continuar estudando python e entendendo melhor a linguagem.
A alguns anos fugi do DJango e do DJango Rest que foram as tecnologias de entrada para o mercado de trabalho que usei, pois esses frameworks apesar de serem muito bons e ajudarem demais no seu desempenho, acabam resolvendo muitas coisas "under the hood" por conta própria, e essa abstração que ele gera pode acabar levando a perda ou ao não aprendizado de conceitos importantes de desenvolvimento. Te recomendo ao mesmo tempo que entende o DJango e seus correlatos a se desafiar em outros frameworks web também, como o Flask ou o FastAPI por exemplo. O Simples fato de aplicar tudo que aprendeu até agora em outros frameworks vai te ensinar demais e mostrar que existem outras formas de resolver os problemas até mesmo dentro das tecnologias que você já conhece!

Espero ter ajudado de alguma forma! ;-)

Carregando publicação patrocinada...
1

acabam resolvendo muitas coisas "under the hood" por conta própria, e essa abstração que ele gera pode acabar levando a perda ou ao não aprendizado de conceitos importantes de desenvolvimento.

Cara, essa foi exatamente a minha impressão. Minha expectativa era que Flask /FastAPI seria assim e por isso eu não comecei com ele.
Por ver ele fazendo muita coisa por debaixo dos panos é eu estranhei. Mas tá aí, acho que vou fazer duas APIs de estudo iguais, primeiro com Django e depois com Flask e aí vou ver a que melhor se encaixa pra mim.

3

Cara, se você estiver montando APIs eu te recomendo demais o FastAPI ou o Flask para sentir a diferença... Neles você é obrigado a resolver muitas coisas por conta própria e ambos tem abordagens diferentes para os mesmos problemas. Fazendo isso, se voltar a usar o DJango algum dia, vai entender muito melhor como aplicar as boas práticas nele!

Sucesso pra você!