Demystifying Django Architecture : A Beginner-Friendly Guide

1. Django's Core Pattern: MVT != MVC ## 2. Understanding Django's multiple folder system ## 2.1 myproject folder under myproject folder ## 2.2 myapp project in myproject folder ## 2.3 How Project and App Work Together ## 2.4 Key Takeaways Django has a reputation: "Powerful....but scary". You install a new project and suddenly you're staring at files and folders like urls.py , wsgi.py , settings.py , apps , models and magic commands like migrate , all before even touching your django project. Unlike Flask’s simplicity in software architecture, Django provides a more structured, batteries-included framework that enforces clear separation of concerns and scalable architecture from the beginning. This guide will demystify Django's structure , why it's designed this way , how each part plays a role in building your modern web applications. While most frameworks such as Laravel , Rails and even Flask extensions follow the classic MVC method (Model-View-Controller) design pattern, Django takes a slightly different by closely related approach called MVT (Model-View-Template) Model defines the database structure and handles data interactions. Template handles what the user sees such as UI rendering. View processes logic, receives requests and return responses. A simple flow of how Django works are shown below: This separation helps developers maintain clean, scalable code. Perfect for complex application with both user features and admin management! Let's take a broader look at a Django project. A Django project is organized into two main types of folders, each serving a distinct purpose: Pretty weird concept right? Well , when you create a django project , you will begin with this command When you run this command , Django will create: Outer folder (myproject/) – This is the project root or workspace. It holds everything related to your project, including your apps, the database, and manage.py. Think of it as the body of your project where all files live. Inner folder (myproject/) – This is the project configuration folder. It contains all the settings and configuration files necessary to run your Django project, such as settings.py, urls.py, wsgi.py/asgi.py, and init.py. Think of it as the brain of your project. Key files in the inner folder: settings.py → Central place for configuration: databases, installed apps, middleware, templates, static files, and more. urls.py → Central routing table for the project; can include app-specific URL patterns. wsgi.py / asgi.py → Entry points for deploying your project on a web server. init.py → Marks the folder as a Python package, enabling imports. Think of the inner folder as the brain of the project, while the outer folder is the body or workspace that holds everything together. After creating a project, you create apps to handle different functionalities. For example: Django creates the following structure: From this structure , Django suggests that : Django's architecture is designed based of separation of concerns.The project acts as the central configuration, holding global settings, URLs, and server interfaces, while each app is a self-contained module responsible for a specific feature, with its own models, views, and templates. This separation ensures that models handle data, views handle logic, and templates handle presentation, keeping the code organized and maintainable. The project + app structure dynamic also makes it easier to scale, as new functionality can be added by creating new apps without affecting existing ones. Thank you for reading , look forward to more software engineering digest! Happy weekend :) Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse COMMAND_BLOCK: User requests -> URL -> View (Logic) -> Model (Data) -> Template (Display UI) -> Browser (Chrome , Opera etc) Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: User requests -> URL -> View (Logic) -> Model (Data) -> Template (Display UI) -> Browser (Chrome , Opera etc) COMMAND_BLOCK: User requests -> URL -> View (Logic) -> Model (Data) -> Template (Display UI) -> Browser (Chrome , Opera etc) COMMAND_BLOCK: myproject/ │ ├── myproject/ # Project settings folder │ ├── __init__.py │ ├── settings.py # Configuration for DB, apps, middleware, templates │ ├── urls.py # URL routing for the whole project │ ├── wsgi.py / asgi.py# Server gateway interface │ ├── myapp/ # Application folder │ ├── __init__.py │ ├── models.py # Database schema (used by both User & Admin) │ ├── views.py # Logic for User side │ ├── urls.py # Routes specific to this app │ ├── templates/ # HTML templates (User side) │ │ └── myapp/ │ │ └── *.html │ ├── admin.py # Admin interface registration │ ├── forms.py # Forms for both User & Admin (optional) │ ├── manage.py # Command-line utility for migrations, running server, etc. └── db.sqlite3 # Example database Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: myproject/ │ ├── myproject/ # Project settings folder │ ├── __init__.py │ ├── settings.py # Configuration for DB, apps, middleware, templates │ ├── urls.py # URL routing for the whole project │ ├── wsgi.py / asgi.py# Server gateway interface │ ├── myapp/ # Application folder │ ├── __init__.py │ ├── models.py # Database schema (used by both User & Admin) │ ├── views.py # Logic for User side │ ├── urls.py # Routes specific to this app │ ├── templates/ # HTML templates (User side) │ │ └── myapp/ │ │ └── *.html │ ├── admin.py # Admin interface registration │ ├── forms.py # Forms for both User & Admin (optional) │ ├── manage.py # Command-line utility for migrations, running server, etc. └── db.sqlite3 # Example database COMMAND_BLOCK: myproject/ │ ├── myproject/ # Project settings folder │ ├── __init__.py │ ├── settings.py # Configuration for DB, apps, middleware, templates │ ├── urls.py # URL routing for the whole project │ ├── wsgi.py / asgi.py# Server gateway interface │ ├── myapp/ # Application folder │ ├── __init__.py │ ├── models.py # Database schema (used by both User & Admin) │ ├── views.py # Logic for User side │ ├── urls.py # Routes specific to this app │ ├── templates/ # HTML templates (User side) │ │ └── myapp/ │ │ └── *.html │ ├── admin.py # Admin interface registration │ ├── forms.py # Forms for both User & Admin (optional) │ ├── manage.py # Command-line utility for migrations, running server, etc. └── db.sqlite3 # Example database CODE_BLOCK: django-admin startproject myproject Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: django-admin startproject myproject CODE_BLOCK: django-admin startproject myproject CODE_BLOCK: python manage.py startapp myapp Enter fullscreen mode Exit fullscreen mode CODE_BLOCK: python manage.py startapp myapp CODE_BLOCK: python manage.py startapp myapp COMMAND_BLOCK: myapp/ ├── __init__.py # Marks folder as a Python package ├── admin.py # Register models to the admin interface ├── apps.py # App configuration ├── models.py # Database models for this app ├── views.py # Logic / controllers for this app ├── urls.py # App-specific routes (optional, you can create manually) ├── migrations/ # Database migrations for this app └── templates/ # Optional HTML templates for this app Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: myapp/ ├── __init__.py # Marks folder as a Python package ├── admin.py # Register models to the admin interface ├── apps.py # App configuration ├── models.py # Database models for this app ├── views.py # Logic / controllers for this app ├── urls.py # App-specific routes (optional, you can create manually) ├── migrations/ # Database migrations for this app └── templates/ # Optional HTML templates for this app COMMAND_BLOCK: myapp/ ├── __init__.py # Marks folder as a Python package ├── admin.py # Register models to the admin interface ├── apps.py # App configuration ├── models.py # Database models for this app ├── views.py # Logic / controllers for this app ├── urls.py # App-specific routes (optional, you can create manually) ├── migrations/ # Database migrations for this app └── templates/ # Optional HTML templates for this app COMMAND_BLOCK: # myproject/urls.py from django.contrib import admin from django.urls import path, include urlpatterns = [ path('admin/', admin.site.urls), path('blog/', include('blog.urls')), # routes from the 'blog' app ] Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: # myproject/urls.py from django.contrib import admin from django.urls import path, include urlpatterns = [ path('admin/', admin.site.urls), path('blog/', include('blog.urls')), # routes from the 'blog' app ] COMMAND_BLOCK: # myproject/urls.py from django.contrib import admin from django.urls import path, include urlpatterns = [ path('admin/', admin.site.urls), path('blog/', include('blog.urls')), # routes from the 'blog' app ] - Apps are modular → Each app is self-contained. - Reusable → You can plug an app into multiple projects. - Organized → Each app has its own models, views, and templates. - Example: You could have a blog app, a shop app, and a users app, all inside the same project. - myproject/ is responsible for the global settings and routing. - Each app that you created contains its own models, views, templates, and logic. - For example , a blog app that you created can register their routes in the project-level urls.py using include(): - This modular design keeps your code organized and scalable, especially for larger projects.