Member-only story
Clean Architecture in Python — When It Helps, When It Hurts, and What I Actually Use
Not every project needs six layers of abstraction.
Anas Issath10 min read·Just now--
I inherited a FastAPI codebase that had been “properly architected.” The developer who built it had read about clean architecture and applied every pattern he could find. There were repositories, services, use cases, domain entities, DTOs, mappers, ports, and adapters. Getting a user by ID traversed seven files across four layers.
To add a single field to the user profile — just adding bio — I had to modify the domain entity, the repository interface, the repository implementation, the mapper, the DTO, the use case, and the service. Seven changes for one field. In a Django project, that's one line in the model, one in the serializer, and you're done.
The architecture was technically “clean.” It was also technically unusable. The team had spent more time maintaining the architecture than building features. Two developers had quit.
Six months later, I refactored an older Django monolith that had zero architecture. Business logic lived in views. Database queries were scattered across templates. The same 20-line pricing calculation was copy-pasted in four different files. When the business changed the pricing formula, someone updated three of the…
