|
|
|
|
|
|
by hbrn
1279 days ago
|
|
|
I mostly agree with you and DHH on that topic, however in my experience reasonably applied SOA/DDD actually shields me from this layering nonsense. 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. Though, admittedly, I found it hard to sell such "inconsistencies" to other tech leaders, most folks aspire to those grandiosities. > If the app starts getting too big for its britches, probably the best thing to do is make it 2 apps That's the argument in favor of SOA, isn't it? |
|
|
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.