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