What is the difference between a Django project and an app, and how should you structure a large codebase?

A project is the deployable unit — settings, root URL configuration, WSGI and ASGI entry points. An app is a self-contained module of functionality with its own models, views, and migrations. One project contains many apps, and a well-designed app is reusable across projects.

How to draw app boundaries: by domain, not by layer. An app called orders containing its own models, views, and services is right; apps called models, views, and forms are wrong — that is just the framework's structure repeated at a larger scale.

What changes as a codebase grows:

• Split settings into base, development, and production, with secrets from the environment rather than the repository.
• Move logic out of views. Fat views are the most common structural problem in Django. Push business rules into model methods, managers, or a services.py so they are testable without HTTP.
• Use custom managers and QuerySets so query logic lives in one place — Order.objects.pending() beats the same filter repeated in nine views.
• Watch for circular imports between apps. If two apps import each other's models, the boundary is wrong.