[hbrn]

The short answer is yes.

The long answer is if two entities are updating each other you might benefit from shifting all update responsibilities to one of them. Or even to a third entity that knows about both and keeps those two isolated from each other.

[cjohnson318]

Woof. Thank you so much. I like the idea of a third party, like a mediator.

Would that mediator be another app? Or should it be some module sitting in the project directory? (I'm not even sure Django would import something like that.)

[hbrn]

> Would that mediator be another app?

Yes!

It is an app that might not even have any model classes. But it will contain business logic. And it will probably speak domain language, which is great.

If you're lucky, those two other apps will become pluggable. You will probably never replace them, but separation of concerns is always nice.

The downside of course is that you will have 3 apps instead of 1. That's the balance you have to maintain.

[cjohnson318]

So, the way I understand it, job/services.py and load/services.py depend on mediator/mediator.py which depends on job/models.py and load/models.py, instead of job/services.py ultimately using load/services.py, and vice versa.

Thanks so much!

[hbrn]

This is good enough to break circular dependencies between individual modules, but keep in mind that circular dependencies between the apps remain (e.g. job depends on mediator, mediator depends on job).

I usually prefer to resolve those too. If job is small enough, all the orchestration of jobs should happen through mediator (same for load). If it's not plausible, then job can emit signals which mediator subscribes to.

A good place to start is to give a more descriptive name to the mediator. Sure, it mediates between the two, but it probably does that to implement some business process. Can you name it after that process?

[cjohnson318]

> ...all the orchestration of jobs should happen through mediator (same for load)

So, in a smaller app, when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two? I was just going to focus on specific tasks between job and load. I'll probably look into signals; I haven't used those in several years and as I recall, it felt hacky.

> give a more descriptive name to the mediator

When a Job is deleted, it needs to delete associated Loads. And the states of the Loads will affect the state of the Job. That's the main cycle I'm looking at right now.

[hbrn]

> when a request comes into job/views.py or load/views.py then we immediately start working with JobLoadMediator to handle business logic between the two?

In my world, mediator.views and job.views would likely have different audiences.

mediator.views is for business domain (e.g. your API). Though name would not be mediator, it would be something domain-specific.

job.views could be for more low-level internal tooling (e.g. analytics/monitoring). Or it could be empty, if job is just dumb data object that has a lifecycle but doesn't require public API.

> When a Job is deleted, it needs to delete associated Loads. And the states of the Loads will affect the state of the Job

If you want to keep them apart, signals is the right (though not the easiest) answer. job owns (depends on) loads, and subscribes to loads signals. load doesn't know anything about job (ignore the fact that job is referenced in load.models as foreign key, that's just limitations of SQL DDL).

The easiest is a subtle dependency: load can access job through foreign key, job can access loads through related_name. Circular dependency is still there, but it is resolved at runtime. This will start to cause pain when application grows, but is fine at small scale.

Though again, I'd probably merge those apps: if you can't reason about load without job, and can't reason about job without load, there's very little benefit in keeping them separate. It might make you feel more organized, but the if the code is lying about your mental model, this is false organization.

[funkydata]

Although it goes against certain opinions AND if you set a norm for their use, signals are the way to go.

You can either decide that signals code will live in the app where the objects reside or the app of the target objects and that's it. A built-in and simple interface between objects.

[cjohnson318]

Holy bovine. This finally worked. I've been working around the clock on this for two days now. Thanks again stranger!

[funkydata]

Also, do not forget to integrate with Sentry [https://sentry.io/] or something that does the same thing.

It will also keep you sane.