However, I think much of the value of having design patterns and fancy vocabulary for architecture boils down to having simple, short names for complicated, yet common, patterns and principles.
For example, if you're being onboarded into a team of twelve to develop an already somewhat large product, the phrase "it's an n-tier application, with many of our older models' data access layers using some kind of CQRS" is immediately meaningful and useful to you, in the same way referring to 1000+ line objects as "adapters" or "aggregates" is meaningful and useful to you.
Having this vocabularly enables communication of an intended purpose and responsibility for arbitrarily large swaths of code in a way that boilerplate documentation and tests can't.
(Naturally, if you're writing something from the ground-up, or you're one of a small handful of developers on the project, the value of this is somewhere between negative and negligible, which might explain the polarization of opinion on this topic...)
However, I think much of the value of having design patterns and fancy vocabulary for architecture boils down to having simple, short names for complicated, yet common, patterns and principles.
For example, if you're being onboarded into a team of twelve to develop an already somewhat large product, the phrase "it's an n-tier application, with many of our older models' data access layers using some kind of CQRS" is immediately meaningful and useful to you, in the same way referring to 1000+ line objects as "adapters" or "aggregates" is meaningful and useful to you.
Having this vocabularly enables communication of an intended purpose and responsibility for arbitrarily large swaths of code in a way that boilerplate documentation and tests can't.
(Naturally, if you're writing something from the ground-up, or you're one of a small handful of developers on the project, the value of this is somewhere between negative and negligible, which might explain the polarization of opinion on this topic...)