[hbrn]

Ah, the typical "where to put business logic in Django".

M in ActiveRecord MVC web frameworks is deeply misunderstood. M is not "data model" (it would be called DVC if that was the case). M is your domain model. It's the model of your business, model of the real world. It's the core of your application.

Another thing that I never understood, why are functions called services? Is it a subconscious desire to go back to enterprisey kingdom of nouns? (apparently it is [1])

A service is either something that lives on a network (e.g. database, payment gateway, microservice). Or a class that has a state. Your functions are neither of those, they are just functions.

You business logic should live in the "models" namespace. Whether you put it on Model classes, or onto custom Managers, or just dump them into the module is not important, as long as you keep it consistent and keep your apps fairly small and isolated from each other.

Django already gives you enough tools to support big "enterprise" applications. It is far from perfect, but you'll get much further if you embrace the framework instead of fighting it.

If you really are attached to this "services" mindset then Django API Domains [2] is your best option.

[1] https://www.b-list.org/weblog/2020/mar/16/no-service/

[2] https://github.com/phalt/django-api-domains

[roflyear]

I never understood why this was so hard or why people complicate this so much. You have a segment of your application that "does stuff" - some mix of classes and functions. This stuff has its own API. Then you have your web views call that code through that API (which is probably just calling functions...).

No, instead, it is that "does stuff" hast to be its own library, or god forbid, its own service that lives somewhere else, with its own communication layer, its own auth...

Why are we making this so hard on ourselves?

[hbrn]

Typically it goes like this:

1. You found one case where complexity is essential.

2. That one case is not consistent with the rest of your app, and you were taught that inconsistency is bad.

3. Since you can't remove complexity from that case, for the sake of consistency you add complexity to all other cases.

Class-based views is a typical example. You found a place where CBVs are useful. Now some parts of your app use functions, some use classes, that's inconsistent. Edit your style guide to enforce CBV everywhere. Now a simple healthcheck endpoint that returns "OK" has to be a class.

As some folks used to say, you can write Java in any language.

The right approach, of course, is to say "I'd rather have inconsistency than complexity". The challenge is that perception of complexity is subjective, but inconsistency is objective. So the right approach eventually loses, and every organization turns into a bureaucratic hell.

[nprateem]

Business logic goes in the controller. That's why it's called a controller because it controls stuff like access to your data.

[crucialfelix]

I try to use controllers just to connect incoming events or API calls to the business layer.

The control part is more like Traffic Controller . Just directing traffic.

[hbrn]

Oh sweet summer child.

Please read this carefully: https://folk.universitetetioslo.no/trygver/1979/mvc-2/1979-1...

Business logic is supposed to be reused. Controllers in web frameworks (views in Django) expose no way to do it.

[nprateem]

If you want to reuse logic you make another http request to the right endpoint.

[hbrn]

Are you just trolling? Or your cronjobs are really making http requests?