HackSoftware/Django-Styleguide
1
1
Fork 0
mirror of https://github.com/HackSoftware/Django-Styleguide.git synced 2024-11-26 11:33:45 +03:00
Code Issues Packages Projects Releases Wiki Activity

Add several paragraphs for more complex Celery scenarios

Browse Source
This commit is contained in:
Radoslav Georgiev 2019-11-03 11:47:56 +02:00
parent 94ea1e92a8
commit b9c741b15a
1 changed files with 10 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
README.md
View File

@ -961,9 +961,18 @@ from project.app.services import some_service_name as service
def some_service_name(*args, **kwargs): def some_service_name(*args, **kwargs):
service(*args, **kwargs) service(*args, **kwargs)
``` ```
This is a task, having the same name as a service, which holds the actual business logic. This is a task, having the same name as a service, which holds the actual business logic.
**Of course, we can have more complex cituations**, like a chain or chord of tasks, each of them doing different domain relateed logic. In that case, it's hard to isolate everything in a service, because we now have dependencies between the tasks.
If that happens, we try to expose an interface to our domain & let the tasks work with that interface.
One can argue that having an ORM object is an interface by itself, and that's true. Sometimes, you can just update your object from a task & that's OK.
But there are times where you need to be strict and don't let tasks do database calls straight from the ORM, but rather, via an exposed interface for that.
**More complex scenarios depend on their context. Make sure you are aware of the architecture & the decisions you are making.**
### Structure ### Structure
#### Configuration #### Configuration