A pouco tempo atrás eu era uma desenvolvedora iniciante, e para quem como eu não tem um background de computação pode ser muito difícil entender o que está acontecendo por baixo dos panos quando fazemos uma aplicação. Para quem está iniciando no mundo da programação com Python e Django e está se sentindo sobrecarregado e perdido com o que acontece nas aplicações, eu vou explicar aqui a forma que eu consegui entender o fluxo da coisa.

A requisição

Partindo de uma aplicação pronta, o fluxo se inicia quando você digita uma url no navegador. A partir daí o Django vai no seu arquivo settings.py e procura a variável ROOT_URLCONF para saber em qual arquivo estão os padrões de urls "conhecidos" pela sua aplicação. Sabendo em qual arquivo buscar pelas urls, o Django então procura nesse arquivo a variável urlpatterns, que contém todas as urls base que a sua aplicação conhece. Eu digo urls base porque esse arquivo normalmente direciona para outros arquivos de urls que contêm as rotas mais detalhadas.

urls.py

Sabendo qual é o arquivo certo, o Django passa por todos os padrões de url em ordem e procura uma que corresponda à url digitada no navegador. Uma vez que role um match ele irá importar e chamar a view associada. Em outras linguagens a "view" é chamada de controller porque é ela que controla como as informações da aplicação serão tratadas e enviadas para o navegador/usuário. Isso pode se tornar um pouco confuso quando se está estudando o padrão MVC (Model-View-Controller), no qual view significa a parte com a qual o usuário interage.

Caso não haja um match com nenhuma das urls na lista, o Django retorna uma exceção indicando que ele não conseguiu encontrar nenhuma url que correspondesse à url digitada pelo usuário. Muitas vezes um erro no programa surge pelo simples fato de você esquecer de adicionar uma url específica ao seu arquivo de urls. Isso pode ocorrer até com os mais experientes dos desenvolvedores.

View

Bom, voltando ao nosso fluxo no Django, quando a view é chamada um objeto HttpRequest é passado com as informações referentes à requisição que foi feita. Esse objeto contém a url chamada e pode conter diversas outras informações como: argumentos passados por meio do corpo da requisição, dados da sessão do usuário, arquivos... Informações que serão usadas pela view para decidir que informações serão retornadas para o usuário. É nesse ponto que o grosso da programação irá acontecer, onde se poderá acessar o banco de dados para buscar informações, manipular os dados recebidos, manipular informações, e fazer toda a mágica do seu programa.

Template

Após toda a mágica e toda a manipulação acontecer, é chegada a hora de devolver as informações para o usuário. Uma view pode conter diversos métodos que lidem com diferentes requisições para aquela url (se é um GET ou um POST, por exemplo) e no final os métodos devem retornar tanto os dados quanto qual arquivo html (template) deve ser renderizado na hora de mostrar as informações para quem fez a requisição. Esse retorno pode acontecer de diversas formas, o Django pode inclusive lidar com as suas requisições sozinho, sem você precisar codar todo o comportamento. Você vai ter que pesquisar para ver qual forma funciona melhor para você, e eu posso inclusive fazer um post sobre isso no futuro.

Sucesso!!

Uma vez que a view retorna as informações e qual arquivo html deve ser renderizado, o Django irá mostrar essa página para o usuário e então (se tudo for feito da forma correta) é só sucesso!!

Espero que você tenha conseguido entender o fluxo de uma requisição no Django, mas sinta-se à vontade para comentar suas dúvidas se não tiver entendido, qualquer dúvida é válida.