[FLT8]

> even just updating the dependencies might sometimes be impossible (in a reasonable timeframe).

Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.

[KronisLV]

> Consider the situation where you have a proliferation of micro-services all using a similar but slightly divergent stack, and you're notified of a security issue that means you need to update the same library across the entire fleet of services. I know what situation I'd prefer to deal with.

That's a valid concern!

But surely there's a middle ground, maybe along the lines of: "okay, this is our main modular monolith codebase, but we'll make the decision to split this one vastly different type of workload in a separate service, since it adds 20 dependencies and we don't want to add that complexity in a codebase that's otherwise a fairly straightforwards RESTful API."

Yet, it's a bit odd, because people often talk about DDD and drawing domain boundaries, instead of "okay, so this group of functionality will need to export PDFs of bills and receipts, so we'll extract that and all of the related functionality because of technical considerations, whereas we don't care about adding 10 more API endpoints to our main codebase, because there's another 200 there already."

Instead, everyone seems to go "ohh, we'll have users in our system, so that's UserService (myproject-locksmith), we'll have orders in the system, so that's OrderService (myproject-bookkeeper), there's also bills so let's make BillService (myproject-scribe)" and so on.