django-patterns

Use a split-settings layout with a config directory containing base, development, production, and test settings modules, plus a separate apps directory for business logic. Each environment file imports from base and overrides only environment-specific values like DEBUG, ALLOWED_HOSTS, and database names.

Use select_related for foreign key relationships and prefetch_related for many-to-many relationships when querying. Encapsulate these in custom QuerySet methods like with_category() so the optimization is applied consistently across the codebase.

A service layer places business logic in dedicated service classes (e.g., OrderService) rather than in views or models. Methods like create_order use transaction.atomic to keep multi-step operations consistent, keeping views thin and logic testable.

Use the @action decorator inside a ModelViewSet, specifying detail=True for single-object endpoints or detail=False for collection endpoints. You can override permission_classes per action and use get_serializer_class to return different serializers per action.

Use signals like post_save for cross-app side effects such as creating a Profile when a User is created, registered in the app's ready() method. Override save() only for logic intrinsic to the model itself, like auto-generating a slug.

Yes, low-level caching via django.core.cache stores evaluated QuerySet results under a cache key with a timeout. Convert the QuerySet to a list before caching so the cached object holds concrete data rather than a lazy query.