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

[cjohnson318]

> mediator.views is for business domain (e.g. your API) > job.views could be for more low-level internal tooling

That's very interesting. I'm mostly following the architecture from: https://phalt.github.io/django-api-domains/styleguide/

I knew this was going to be a large project, about 19 apps, supporting a trucking and inventory web/mobile app, and I wanted a sane/organized way to deal with all of the models and relations.

Do you know of some blog posts or books that go into the way you normally organize things?

> if you can't reason about load without job, and can't reason about job without load

There is a lot of interaction between all of the parts of the app, but particularly between Jobs, Loads, Inventory, Stages, and Drivers. In the future I might start with one app, and then add another if I absolutely have to.

[funkydata]

If you try to keep everything in one app, you'll have gigantic views.py, models.py, etc.

Nobody wants to work with those. Also, a simple typo in those files can bring your whole system down and can make it hard to debug.

Apps, are a cheap (EXCEPT when you HAVE TO [but really, do you? Really?] move models between apps) way to keep YOU sane.

[cjohnson318]

Right, no one wants to work on a 10k line view.py file. However, if you put everything into its own app, like I did, then you run into circular dependencies as your project gets closer to feature complete. So, the answer is somewhere in the middle. At the moment, I have about 20 apps, with 1 to 4 models per app, and 20% of all that is highly interdependent. I should have put the big, highly interdependent pieces in one app, and have the less connected pieces in separate, bare-bones crud-apps.

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