That’s not quite an accurate restatement, no.
I’m saying the two concepts (“Clean architectural principles” and “Django’s way of organizing code”) are two different and non-overlapping issues. The architectural principles will identify what functionality will be provided by which objects or functions. The organizing code identifies physically where those functions exist within your source directory tree.
Now, while that’s the basic and direct response, the reality is a little more subtle than that. Django does have an architecture, with its associated principles - one that has been proven to work extremely well under a variety of circumstances. To say that:
is ignoring the architecture that does exist. The friction that gets created when a developer ignores Django’s architecture is the “mental disconnect” created when someone who is familiar with Django’s architecture has to bridge the gap between their understanding of how Django works and how your application works caused by the mixture of architectural patterns.
Keep in mind that “Architectural Principles” are just that - principles. They’re not rules or requirements. They form a basis for making decisions.
Never lose sight of the fact that the overall objective of adopting a set of principles is to enhance reliability, maintainability, and extensibility of a system - in other words, minimizing the cost of that system over its entire life cycle.
The skill of an architect is understanding these decision points, and how those decisions may affect and be affected by future environmental changes - and what the cost may be to implement those changes later.
(I’ve seen way too-many over-engineered systems designed to handle situations with < 1% probability of occurrence over a 20-year lifespan of that system - such as a mainframe system developed in 1990 with a separate “data access layer” because “we might want to change databases” as if IBM DB2 was going to go away in an environment where it was responsible for 95+% of all corporate data.)
So yes, if you’re building your system around Django, your architectural decisions should reflect that. Otherwise, you’re wasting time, money, and “mental effort” trying to achieve some “ivory tower” architecture that may or may not be suited for the environment in which the real system is being built - or worse, trying to replicate an architecture built for a different framework. Django is not Spring, .NET, or Symfony - there is no value in trying to replicate application architecture among the four.
(All this comes from working as an Enterprise Architect for a little more than 5 years in a large multi-national corporation. I was formally trained in the application of TOGAF 7/8 as an enterprise architectural framework, and was a member of the team that developed the corporate IT architectural principles for the US division.)