- Tags:: 🗞️Articles, Django, Software Architecture
- Author:: James Bennett (developer)
- Link::
- Source date:: 2020-03-16
- Finished date:: 2020-10-31
It’s a reaction to a style guide around there: https://github.com/HackSoftware/Django-Styleguide
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”. And adopting the service approach essentially means that, whatever your business was previously, now your business is that plus developing and maintaining something close to your own private ORM.
What to do instead:
the base pattern is “things that involve one model instance go on the model class; things involving multiple or all instances go on the model’s
QuerySetor manager”.
And for cross-cutting logic that doesn’t make sense in a model, messaging could be one solution. Although the author says that there are many other patterns to break these complexities. The whole point is that if you have a method that does a lot of things, that’s the problem, and it’s not solved by putting it in a service layer.
often what’s really wanted when breaking up these complex cross-cutting methods is a way to have many different components work together but not necessarily have to possess knowledge of, or directly invoke, each other. Having each component publish messages about what it’s doing, and requiring others to subscribe and react to the specific types of messages they care about, can accomplish this.
I was hesitant to get into this in the previous post because there’s no easy answer. There are a lot of patterns for designing software to handle this type of complexity without having to put huge chunks of it into just a few overburdened methods or classes, but none of them are one-size-fits-all. To take one example: in the reddit thread for the previous post I mentioned that several larger codebases (both Django and non-) I’ve worked with have eventually integrated, or at least bolted on, some type of publish/subscribe message broker.
Two Scoops of Django considers also mixins, and stateless helper functions as alternatives.