"The web framework for perfectionists with deadlines." This is what Django says it is and that is actually true indeed. But what if you are a perfectionist and the deadlines don't matter much as much as the extensibility and maintainability? Django will provide you with the platform where you can build CRUD operations using Forms and Generic Views very fast but for most of the projects, clients/your boss will come and ask you to implement something which is not controlled by the code you wrote, but by the Django. For example: the creation of a Model object from Form or Serializer. How will you prevent DRF (Django Rest Framework) from calling in Retrieve operation with a viewset, maybe in order to improve some sort of performance issue? get_queryset() There are a lot of such scenarios where you need to come one step back and implement things using a Django-Antipattern. I faced the same issues while working on projects @ and . We used so much Django in Django applications that a small change could require either creating a simple API View among viewsets. That no doubt had an impact on code readability and documentation. And when more than one person is working on a project, it matters more than the code itself ;p. crove.app untether.tech So, after looking a lot and checking out what other guys are doing, I came to know about the style guide and practices that I wish I knew before starting the project. The style guide enables you to take control of the application. No doubt there's an overhead of doing the things like CRUD operations using API that could've done by simply creating a viewset. But, there's a but ;p (I borrowed this line from my friend) While working on a project that you think will take a minimum of 5-6 months to build by more than one person, I recommend you to not take chance on the abstraction that Django and Django's REST framework provides. Business rules change every now and then, but someday, , they won't allow. Here is the quick overview of the style guide, I am talking about, that defines the of where the business rules, should be placed while working in Django. Generics boundaries In Django, we have: 1. Models 2. Views 3. URLs 4. Forms 5. Serializers (DRF) 6. Viewsets (DRF) 7. Permissions (DRF) To put business logic, we need some other box, which we can call as: 1. Services 2. Selectors Services Services serves the business logic. They satisfy the business needs and do operations that the business needs to do. For Eg: Sending an email, Creating a user, Creating a blog post, Blocking a user, Creating a comment etc. We use services in views, tasks, models, etc. Selectors Selectors return what we ask for. For eg: get_active_users, get_top_posts_for_users, get_comments_for_post etc. We use selectors in services, views, tasks, models, etc. Instead of views, models, forms etc. why not just test the services and selectors, because this is where the business logic is placed. Best Thing: testing Styleguide Copy-pasting style guide here from the Github repository, would not be a good idea, so you can visit: to check it's contents. https://github.com/HackSoftware/Django-Styleguide It talks about the and only so I don't think you'll face any issue while checking it out. services selectors Keeping your business logic in services and selectors actually help a lot. As I said, there's an overhead of calling services and selectors and creating bare APIViews/ListViews etc. but It'll pay off if you think the business logic/rules will change. Let me know your viewpoints by sending me a message on . Github Recommended: Gary Bernhardt ( Boundaries )

2022 - HackerNoon Contributor of the Year - Code Quality

Nominated for 2022 - HackerNoon Contributor of the Year - Code Quality

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Django Boundaries - Models and Views are Not Enough

Too Long; Didn't Read

@charanjitsingh

RELATED STORIES