Addition to Why not put your business logic in APIs / Views / Serializers / Forms?"" · Issue #170 · HackSoftware/Django-Styleguide (original) (raw)

Skip to content

Navigation Menu

• • GitHub Copilot Write better code with AI
  • GitHub Advanced Security Find and fix vulnerabilities
  • Actions Automate any workflow
  • Codespaces Instant dev environments
  • Issues Plan and track work
  • Code Review Manage code changes
  • Discussions Collaborate outside of code
  • Code Search Find more, search less
• Explore
  • Learning Pathways
  • Events & Webinars
  • Ebooks & Whitepapers
  • Customer Stories
  • Partners
  • Executive Insights
• • GitHub Sponsors Fund open source developers
  • The ReadME Project GitHub community articles
• • Enterprise platform AI-powered developer platform
• Pricing

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sign up

Description

Hi, just read the style guide, looks good, quite similar to what I think!
Small note to "Why not put your business logic in APIs / Views / Serializers / Forms?" section:
third should be - business logic doesn't related anyhow to way-you-call-it/transport/endpoint and just because of that it should be separated - you may want to call service function from management command, periodic task, admin action whatever, but if you placed it in HTTP API it makes it difficult (e.g. you need to have special API user, perform not needed network call etc).
It's sort of mentioned in another place:

We try to treat Celery as if it's just another interface to our core logic - meaning - don't put business logic there.

but perhaps good to mention it in a main place.