4 ms·
> 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
by cjohnson318 4y ago
> 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/ 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 4y agoIf 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 4y agoRight, 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.