> 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.
