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.
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.
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.
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?
That sounds to me like good old "replaceable parts oriented programming".
Replaceable parts can have inheritance, but often what is good about them is the composability. Each part can connect to each other in different ways. We call these boundaries "connectors".
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.