u/PrizeThing6131

One of the things I have changed over the years is how much structure I put into a Django project before building the first real feature.

Django’s default project structure is a good starting point, and for prototypes or smaller applications I am quite happy to keep things simple.

The problems tend to appear later.

A single settings.py grows environment-specific conditionals. The default user model becomes difficult to replace. Business logic starts appearing in views. Shared code gradually accumulates in utils.py. Deployment configuration lives partly in the repository and partly in someone’s memory.

None of these are particularly difficult problems at the beginning of a project.

They become much more expensive once the application has production data, integrations and multiple developers working on it.

I now make a small number of structural decisions early:

- Split settings by environment
- Create a custom user model before the first migration
- Organise Django apps around business responsibilities
- Keep the core app deliberately small
- Give business logic a clear home outside the HTTP layer
- Treat APIs as another interface to the same application logic
- Keep infrastructure such as storage and email configurable
- Make testing and deployment part of the project from the beginning

The important distinction for me is that this does not mean building everything on day one.

I do not need Redis, Celery, Sentry or cloud storage running locally before I have written a feature. I just want the project to have an obvious place for those concerns when they arrive.

That is the balance I try to strike between keeping Django simple and avoiding completely predictable restructuring later.

I have written up the full project structure I use, including settings, apps, services, APIs, background tasks, infrastructure, testing and deployment:

https://www.digitaledgeconsulting.co.uk/blog/how-i-structure-a-django-project-for-production

As with my previous post about service layers and thin views, this is not intended as the correct way to structure every Django project.

It is simply the structure I have arrived at after building and maintaining larger Django applications in production.

I would be interested to hear which decisions other people make at the start of a production Django project, and which ones you deliberately leave until later.

I posted here recently about using a service layer in Django and received some genuinely useful feedback.

One of the reasons I introduced that structure was to stop views from gradually becoming responsible for everything.

I have worked on plenty of Django projects where a view starts small, but over time ends up handling form validation, permissions, database queries, audit fields, notifications and business rules.

The code still works, but the responsibility of the view becomes increasingly unclear.

The principle I now try to follow is simple:

A Django view should process an HTTP request and return an HTTP response.

In practice, that usually means the view:

- Checks the request and permissions
- Validates the submitted data
- Calls the relevant application logic
- Converts the result into a response

The important part is not making every view as short as possible. It is keeping logic that does not depend on HTTP out of the view.

I have written a practical walkthrough showing a view before and after refactoring, how I separate input validation from business rules, and how the same logic can then be reused from an API or background task.

How to create thin Django views

This is not intended as the only correct way to structure Django applications. It is simply the approach I have arrived at after maintaining larger production projects and seeing where complexity tends to build up.

At our agency, Wagtail is our go-to framework for building CMS-driven websites.

Over the past few months, we have had an increasing number of clients asking how accessible and understandable their website content is to LLMs, answer engines and other automated tools.

Rather than implementing this differently across every project, I started building wagtail-machine-readable.

The package provides a straightforward and flexible way to expose existing Wagtail content in structured, machine-readable formats, including:

- /llms.txt and /llms-full.txt
- Markdown versions of individual Wagtail pages
- StreamField-to-Markdown extraction
- JSON-LD structured data
- AI crawler controls and activity reporting
- Multi-site support
- Static export for CDN and static hosting workflows

The intention is not to suggest that adding an llms.txt file guarantees that content will be indexed or surfaced by an LLM. The aim is to give Wagtail developers more control over how their content is made available to machines in predictable and usable formats.

We have been testing and refining the package internally, and I now feel it is ready to share more widely before moving towards version 1.0. I would really value feedback from other Wagtail developers, particularly around:

- Installation and configuration
- How well it handles other real-world StreamField implementations
- Whether the default behaviour feels sensible
- Compatibility issues or edge cases
- Anything you would expect to see before a 1.0 release

PyPI:
https://pypi.org/project/wagtail-machine-readable/

Any feedback or constructive criticism would be genuinely appreciated. Thanks!

Over the years I’ve gradually started introducing a service layer into my Django applications.

I found that as projects grew, business logic would often end up spread across views and models. Views became bloated, rules were harder to reuse, and it was not always obvious where a particular piece of logic belonged.

My current approach is to have a reusable base service, with model-specific services extending it. Views interact with the service rather than accessing Model.objects directly, while the models remain focused primarily on the data itself.

A simplified version looks something like this:

```
from typing import Generic, TypeVar

T = TypeVar("T")

class BaseService(Generic[T]):
model: type[T]

def __init__(self, user=None):
self.user = user

def get_queryset(self):
return self.model.objects.all()

def list(self, **filters):
return self.get_queryset().filter(**filters)

def create(self, **fields):
instance = self.model(**fields)
instance.created_by = self.user
instance.full_clean()
instance.save()
return instance

def update(self, instance, **fields):
for name, value in fields.items():
setattr(instance, name, value)

instance.updated_by = self.user
instance.full_clean()
instance.save()
return instance
```

A model-specific service can then handle its own rules and queries:

```
class ProjectService(BaseService[Project]):
model = Project

def get_queryset(self):
return super().get_queryset().filter(created_by=self.user)

def create_project(self, payload):
return self.create(**payload.as_dict())
```

The view is then kept fairly lightweight:

```
@login_required
def project_create(request):
form = ProjectForm(request.POST)

if form.is_valid():
service = ProjectService(request.user)
service.create_project(ProjectPayload(**form.cleaned_data))

return render(request, "project_form.html", {"form": form})
```

This has worked well for keeping business rules in one place, particularly when the same logic is used across standard views, HTMX endpoints, management commands or APIs.

I’m still refining the approach, and I’m curious how other people structure this.

Do you use a service layer in Django, keep the logic on models, use standalone functions, or follow another pattern entirely?