Actually I’ve not read Christopher Alexander’s books like The Timeless Way of Building. While it’s a book about architecture, there’s a concept which the author calls quality without a name that should strike you.

In summary, Cristopher Alexander defines that there’re some things that can’t be named but they’re still considered to have quality.

Do design patterns are quality with name?

Perhaps many software developers are currently implementing their software following many paradigms and architectural design patterns, and there’ve been a trend since more than 20 years which dictates that good software should follow certain design patterns. We would say: don’t reinvent the square wheel, there’s a design pattern to solve this problem.

That is, most developers consider that a software implementing paradigms and design patterns are done with quality in mind. Consider that you’re implementing a solution based on domain-driven design. Just try to discuss with someone behind such development if it has quality or not and you’ll end up with a pointless discussion.

Does domain-driven design mean quality software by definition? I don’t think so: it’ll depend on a lot of things, because the fact that you claim that your solution has implemented domain-driven design doesn’t mean that it does at all, does it?

Does calling a class with a suffix like Service turns your class into a service layer? This is what I call heroic naming and I consider it an anti-pattern.

You know that all questions are answered with a great NO!

My understanding of design patterns is that their motivation is working as generalized solutions to influence yours. Does this mean that implementing design patterns turns out that your solutions have quality? No.

What really makes the difference are your choices and how you end up implementing your software solution. Do some parts of your software look like some existing design pattern?. Don’t hesitate to suffix those parts that can be easily recognized by a known design pattern, because every collaborator will have an easier path to understand your solution, as there’s a lot of documentation and tons of books about them out there!.

Hence, you should find in design patterns a way to get inspired and start software architecture discussions founded on previous community’s knowledge, and don’t use them to excuse a poor quality with a name.

In summary, I would conclude that design patterns aren’t quality with a name because they’re not about quality, but about approaches to solve certain problems that need to adjusted to your actual use cases: they’re not the Ten Commandments of Software.

Hereby, your software is quality without a name depending on how you defend it!. It has nothing to do on how you architect it.