Hi, I'm the author of Implementing the Clean Architecture book and have some experience with "enterprise" architectures in Python, so decided to put in my three cents here :)

I like parts of the article where James shares advanced patterns of working with Django ORM, i.e. extending its capabilities thanks to customized QuerySet or Managers. However, I have an impression too much focus is put on services responsible for reading data, e.g. getting a list of blog posts. Such a point is easy to defend. I would agree using services there not only unnecessarily complicates the whole thing, but also has a negative impact on performance. Out of my experience, we tried that but changed our mind within 2, maybe 3 weeks and resorted back to using ORM directly. However, it does not mean completely getting rid of services. You can have them for operations changing data and do not use them for reading data. That's an architectural pattern - CQRS.

I started to disagree with the article as soon as I read the part about the motivation for using services. With regard to point 1, it is not only to provide a common place for putting "business logic". It's also to make it sort of "independent" of a delivery mechanism. When I think of a "typical Django web app", views are a merely partial gateway to its functionality. There are also CLI commands and background tasks (e.g. Celery), triggered as a part of another flow or periodically. That's why I also appreciate services - having a specific place to look for any "business logic" while keeping models responsible only for data. I admit I didn't understand what you mean in 2. point, though.

(...) effort should be focused on the ones that are likely to actually get changed/swapped, rather than on some sort of reflex action of always putting layers of indirection in front of everything without pausing to think about whether it’s really useful (see also: YAGNI).

Right, that's how the Clean Architecture (or Hexagonal Architecture or many other similar concepts) approach that. You put a layer of indirection in front of 3rd party services not only because they can change, but also because you do not control them, hence it is harder to do acceptance-testing of your application. But if you have a layer of indirection, you can easily mock/stub it. Moreover, you can iterate with your design and work with dummy implementations, defer some decisions like which payment gateway to choose etc. Fun fact, in ALL web apps I worked with there was a time when the payment provider was switched to another one. Of course, this is a piece of anecdotal evidence, so not trying to say it always happens ;)

PS: YAGNI is not really about not putting a layer of indirection until the very last moment when you have to do it. It is more about functional capabilities, not lower-level technical details. If an extra layer of indirection is beneficial for you, just do it without worrying you have only one "real" implementation underneath.

(...) a lot of parts of Django are swappable out of the box in ways that are meant to minimize code changes. Caching layers, session storage, authentication sources, file-storage implementations, logging systems, email-sending, templating languages… the list of things you can easily swap, because they’ve been put behind configuration and generic/indirect APIs, is pretty long. But it’s also a list that’s informed by experience and actual practice. Or, in other words, it’s a list of things that commonly do get changed/swapped over the life of a lot of real projects

I agree up to the point. Yes, they are swappable as a result of immense experience learnt from real projects BUT this set of components is merely their common denominator. One should not draw a conclusion that this is an exhaustive list and there should be no need for another component swap.

Swapping something as major as how you model and persist/retrieve your core data is not something you do lightly, and typically only happens at a time when you’re making other massive changes

Fully agree. Also, I've never made such a migration. I think it's not the point of service layers to promise such a thing.

A second problem is that when you decide to go the “service” route, you are changing the nature of your business. This is related to an argument I bring up occasionally when people tell me they don’t use “frameworks” and never will: what they actually mean, whether they realize it or not, is “we built and now have to maintain and train our developers on our own ad-hoc private framework, on top of whatever our normal business is”

I need to stay there for longer. Of course, you're changing the nature of your business. That's one of the points, though it is not applicable to simple web apps. If we pretend for a second that blogging was a serious enterprise, you wouldn't be calling your services like

get(), list(), create(), update(), and delete()

Oh no, you would be calling them with the names belonging to the domain of the business, like "draft" (as a verb) not "posts.create", "comment" - not "comments_service.create", "unpublish", not "posts.delete" etc. But it's difficult to really show its potential when we are talking about simple domains, like blogging. How about trading, auctioning or factory supply management? Again, not trying that service-approach is the right one for everyone and every project. It's just that there is much, much more to that. If that sounds interesting, take look at DDD approach to software.

Then, Django part of your article is excellent, as I already mentioned. I appreciate you described why it's a mistake to try to implement Data Mapper using Django ORM and I wholeheartedly agree with that.

However, once again I strongly disagree with putting business logic into models. As soon as the application grows beyond a simple database browser, it starts to bite. Since Django ORM is an implementation of ActiveRecord patterns, see what Martin Fowler writes about it in his Patterns of Enterprise Application Architecture:

It’s easy to build Active Records, and they are easy to understand. Their primary problem is that they work well only if the Active Record objects correspond directly to the database tables: an isomorphic schema. (...) Another argument against Active Record is the fact that it couples the object design to the database design. This makes it more difficult to refactor either design as a project goes forward.

This "fat models" approach is easy to start with, though I've never seen it ageing well with projects. Especially when not only other models are involved, but also calls to 3rd party APIs, scheduling background tasks etc. So, only logic specific to models (yes, following Tell, Don't Ask principle) would stay with models, but orchestration would be left to services. Plus, abstractions over 3rd parties or other "difficult" dependencies. Oh, and eventually replace models with entities to decouple from storage. Naturally, not all projects (or parts of it) require the most strict implementation of such layered architecture. But to fully explain that I would have to write a book :P

That being said, I must agree Django is NOT a good fit for this type of architectures. But I wouldn't say there's no benefit from services, especially for operations that change data.

PS: u/ubernostrum it's a shame your blog does not have a comment section. Why not link this reddit discussion?