[forgotusername6]

I read this article and I'm left with the feeling that my entire application has no layer 3 i.e. the component layer. No single (useful) part of the application can be said to have a well defined interface or to be self contained. The strange thing is that I'm not actually that unhappy about that. I'm now sitting here thinking whether I should be more worried.

[Roritharr]

From my experience what you are experiencing is a case of "the current architectural best practices disagree with what we are doing successfully" which many organizations and Senior Engineers interpret as reason enough to introduce change. You will probably receive comments along those lines, be in arguments around this.

You could also actively ignore this for half a decade and see if the tides are changing again. I can almost taste a push towards "lower amounts of abstraction levels and system boundaries lead to smaller stack traces which have xyz advantages" on the horizon. Hang in there, solve the problems you have.

[quickthrower2]

Just need a new name for monolith. “Partition Tolerant System Design” perhaps.

[hnlmorg]

I assume the PTSD acronym was intentional?

Either way, it’s a genius name.

[chrisweekly]

haha, yes, had to be intentional. pitch-perfect.

[alemanek]

I like that. We could always dust off “Modulith” as well.

[WJW]

It kinda depends on the scale I guess? At some point in the growth of on application, pulling out the Big Tools can be helpful to get your application out of a local maximum.

Not everything needs that level of design though. Just because architects do detailed FEM analyses for skyscraper design doesn't mean your garden shed needs the same level of attention.

[philipswood]

This. So much this. I call it the-don't-put-a-golden-handle-on-an-outhouse-door principle.

[Closi]

Depends on your application - A game engine won't break down into this 4 layer model, but lots of enterprise applications (or ecosystems) will.

If an application continues to grow, and the team building it grows, it will eventually need to be broken apart into smaller independent blocks to make it practical for a large team to work on it and maintain it. In a smaller codebase with fewer engineers, you can make different choices.

[lionkor]

Honestly, this may be because you write procedural/functional code, aka simple code, and not enterprise (tm) (R) OOP "I've memorized all 150 design patterns" code.

A lot of these components are strongly linked, and will hold mutable references to each other, which is often pretty terrible.

In procedural code world, everything is connected to each other, but not strongly, and there are very few mutable references.

You may just have a solid codebase.