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