[hellojesus]

Idk if it's best practice, but I usually like to make apps similar to components, where I have an app for accounts which handles user accounts, and a files app which handles all the dimension and fact tables around user uploads, and a social app for social features, etc.

It makes it easy to compartmentalize the business logic in terms of module imports.

[globular-toast]

This sounds similar to a modular monolith design. But you have to be careful not to directly import things between apps and especially not to make foreign keys between the models of different apps. We ended up doing that and just wishing it was one big app.

Modular monolith is a good idea and if you want to do it in Django then make small apps that just expose services to each other (ie. high-level business functions). Then have a completely separate app just for the UI that uses those services.

[hellojesus]

Yeah. I was thinking a modular monolith since it's a django project, and I think that's django's sweet spot since it comes with so many things bundled.

For a true modular design I'd probably step away from django to a less comprehensive framework or just write in golang.

[alganet]

Have you tried the monolithic composite approach instead?

[hellojesus]

I haven't heard of this, and my searches are failing for an exact hit. Do you have a link or can you give a brief explanation please?

[alganet]

It is quite vanguard technology.

A composite is a structure of many pieces that work together.

Thus, a composite monolith is this arrangement of components in a way that they work together as a monolith. Separate modules, but working together as a single thing.

[globular-toast]

That's the same as what people are calling a modular monolith, no? The key thing with composition is the bits sit next to each other, there's no inheritance or dependencies between the components. In my idea you'd have a bunch of "pure service" apps that are focused on individual areas of the business or processes. Then you'd have one or more UI apps (either user-facing HTML or APIs) that compose those services to do what needs to be done, e.g. a "create order" endpoint might compose the create order service from fulfilment and the send notification service from comms to put an order on the fulfilment backlog and send notifications. Is this what you had in mind?