[camgunz]

> When your apps live as a service on the network or as a nicely isolated module in your repo, you no longer have a reason to over-engineer them. You don't need a grandiose architecture that solves every problem, instead you can make local decisions that are good enough in the specific context.

Totally agree yeah, it's a huge boon to engineers to focus on their tickets rather than to have to constantly consider application architecture. I think as long as a framework exists (either an off the shelf one like Django or even--shudder--an in-house one) you get this benefit.

My problem (and maybe we agree here too) comes from the dynamic where the team decides on SOA, and embarks on this saga of implementing the "framework" themselves. That's a big loss in productivity as now you have 2 software projects: your framework and your business app.

> That's the argument in favor of SOA, isn't it?

Eh, not really. I don't think anyone disputes that big apps should be multiple services. SOA/DDD/Hex/etc. aren't novel for suggesting that, their novel claim is that you can tame the complexity of an enormous service by rigidly adhering to their principles when structuring and implementing it. My counterargument is that it's simpler and easier to split services before they become enormous.