I feel the same way much of the time.<p>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.<p>For example, if you&#x27;re being onboarded into a team of twelve to develop an already somewhat large product, the phrase &quot;it&#x27;s an n-tier application, with many of our older models&#x27; data access layers using some kind of CQRS&quot; is immediately meaningful and useful to you, in the same way referring to 1000+ line objects as &quot;adapters&quot; or &quot;aggregates&quot; is meaningful and useful to you.<p>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&#x27;t.<p>(Naturally, if you&#x27;re writing something from the ground-up, or you&#x27;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...)