Repository navigation
Comments on the Django implementation #358
Description
I've learned a lot from Cosmic Python last week, and was inspired to write my version of the example project with Django. Note that I've set out to use more of Django's features while discussing the applicability of the book's patterns to Django projects.
Unfortunately, I feel like the book is a bit too anti-Django, and I say that as a Django fan. The idea that "Django is good for small CRUD projects only" feels too reductive given the amount of features it has.
Personally, I'd like that a future edition of the book had a new appendix presenting maybe a few more Django features and an implementation that shows how useful Django can be, beyond just the ORM. Also, I'd like to contribute to that Appendix, if at all possible/desirable.
Activity
hjwp commentedon Sep 20, 2025
Hi Bruno, am absolutely delighted to see you taking an interest in the book, and see you devoting energy to producing your own guide to how to work with Django.
I currently work for an organisation that has a Django app with 10 million lines of code and somewhere in the region of 5,000 models, and I am absolutely traumatised. My opinion that you should avoid using the Django ORM in your domain model for anything other than the simplest of applications is stronger than ever i'm afraid!
brunodantas commentedon Sep 20, 2025
Appreciate your response! And I'm sorry you're traumatized from what it sounds like the fat models pattern. Could you elaborate on your pain points in that?
In my project, I think I found a good middle ground when defining domain models. My ORM models mostly care about modeling the DB, while the business logic is segregated to a
logicmodule. I feel like that makes the application simpler and a bit more Cosmic, while avoiding the code duplication of domain models vs ORM models.hjwp commentedon Sep 29, 2025
OH YOU WANT TO HEAR MY PAIN?? I'D BE DELIGHTED TO SHARE. lol.
one example is the pain of database migrations. I was looking at a model and wanting to rename it -- i found its name didn't reflect the ubiquitous language of the domain well, i wanted to rename it from "ThingProcess" to "ThingJourney" basically.
the problem is that db migrations are high-risk and so we tend to discourage them unless absolutely necessary. So instead I had to try and convince django to just change the model name but not the table name. That was only a tiny bit fiddly.
The really fiddly part was trying to rename all the FK fields that are pointing at that model, ie i want things to refer to
my.journeyinstead ofmy.process. For about 5 "journey" tables, each one of which had 5-10 FKs pointing in, that was a much more fiddly process, and in the end after spending 3 and a half hours on doing just one of my 5 models, I gave up.So, that's an example of how coupling your domain model directly to your database via an ORM introduces friction to being able to evolve your domain model and ubiquitous language. so much friction, in my example, that it stopped being worth it. that's incredibly depressing.