Django Boundaries - Models and Views are Not Enough

"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

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 @ crove.app and untether.tech. 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.

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,

Generics

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.

Best Thing: Instead of testing views, models, forms etc. why not just test the services and selectors, because this is where the business logic is placed.

Styleguide

Copy-pasting style guide here from the Github repository, would not be a good idea, so you can visit: https://github.com/HackSoftware/Django-Styleguide to check it's contents.

It talks about the services and selectors only so I don't think you'll face any issue while checking it out.

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 )