Using multiple inter-dependent apps – is this structure overkill?

Hi all,

I’m relatively new to Django and have been reading about structuring projects for a site I’m working on. I’m currently structuring it with several apps, but I’m wondering if I’m just adding unnecessary complexity.

The site is an archive (of different types of item) and I’d like to keep the instance-specific requirements separate from the potentially re-usable general structure (as much out of development curiosity as an expectation of it being re-used).

Here’s a reduced sample of the kind of structure I’m thinking of:

archive_app:
Models:

  • Item
  • Tag

people_app:
Models:

  • Person
  • PersonRole (e.g. author, editor, contributor etc.)
  • ItemPerson

etc.

An archive_app.Item can then be associated with a people_app.ItemPerson via foreign key.

people_app.admin then creates a TabularInline to edit ItemPerson and appends it to the Item editor by directly editing the inlines registry (e.g. admin.site._registry[Item].inlines.append(ItemPersonInline)).

If the archive just had e.g. books, these apps would be enabled. If it also included periodicals, a similar periodical_app would create inline associated Models in the same way. There are many other apps that would be needed for the project, all set up in a similar way.

From what I can see, the downsides of this are:

  • Apps are inter-dependent - all would depend on the core archive_app.
  • The ‘Item’ model wouldn’t “know” which other models are associated with it (not having a many-to-many foreign key field), though this reflects a typical many-to-many DB structure.
  • More complexity in importing/managing multiple packages.
  • Directly modifying the admin registry is probably a bit hacky (?)

I’m curious what others opinion is? I’m wondering if I should simplify the whole thing and stick to a single app. Any advice from people with experience of sites with large numbers of models would welcome. Is this just over-engineered?

This is a topic discussed here numerous times in the past.

See I need help with what should be an app and what shouldn't - #2 by KenWhitesell to get started. (There are links to links to links, etc - there’s a lot to read here about this.)

Our basic position is “One app until it hurts, then think about creating multiple apps.” What this really means is that we don’t preemptively start the design of a system around multiple apps. The decision to create those apps have to come from the design, not by driving the design in that direction.

Thanks Ken. I suspected I was trying to shoehorn in a design that didn’t really suit Django; I suppose I had in mind that the “core” should only have the strictly necessary models, but it was starting to look like the wrong approach!

Thanks for the links – I’ll do more reading on the subject, but I probably need to get back to basics on this.