Today we expect every professional Software Engineer to have a good knowledge of Design Patterns. In particular, the names of the patterns in the Gang-of-Four (GoF) book became part of the common vocabulary of software developers. Any good programmer should know the meaning of a Visitor, Singleton or Strategy.
These patterns are part of the general knowledge shared by most professionals in the software industry, independently of the specific fields they are working on. People implementing systems as diverse as games, banking and telecommunications can still apply the same patterns. The GoF Design Patterns widespread usefulness is derived from their generic and abstract properties.
However, to be able to perform our jobs effectively, besides generic knowledge we also need domain-specific knowledge. People developing games have to solve some particular problems that are different from the ones in banking and telecommunications applications. With time, the experts in games programming will have acquired valuable knowledge about how to approach the challenges specific to their field.
Imagine a professional has two set of tools:
- The first set has the common tools used by all other people in the same profession. These are multi-purpose tools that you can buy at any store and are easy to find.
- The second set has very specialized tools that the professional himself has invented. The creation of these tools was the result of many years of experience solving some very specific kinds of problems.
Of course other professionals could benefit from this second set of tools. But then you need ways to share these tools with them.
In the case of software development, we are very good at applying the generic and abstract design patterns. But we still need better methodologies to:
- Identify design patterns specific to our problem domain.
- Classify domain-specific patterns according to their purpose.
- Document domain-specific patterns so that they can be easily understood.
- Collect domain-specific patterns in a repository so that they can be easily shared.
I think that every software development organization should invest resources to create its own collection of design patterns. Every developer in the organization should be aware that he is expected to identify new patterns, classify and document them, and then add them to the shared repository.
I believe that the benefits for the organization are clear. They include:
- Sharing and preserving knowledge in an effective format.
- Creating a common vocabulary.
- Helping new developers learn about the domain.
- Increasing developer productivity by providing reusable solutions.
- Improving software quality by using solutions that were already tested.
So good luck collecting your own design patterns!
Effective Software Design 
Other professions has long supported this dual model, as every Doctor in the hospital has his Stethoscope, but a Heart Surgeon, Dentist, or have also their own set of tools.
SW Eng. is a relative new profession, but still there is plenty of sharing (due to the proximity of our profession to internet and collaboration). As a sample, OOPSLA – http://www.oopsla.org (now SPLASH) has been doing design patterns for more than two (!) decades now. They published and debated contributions of specific DP ranging from vertical domains (e.g. mobile, financial) to horizontal domains (e.g. distributed systems, clouds).
Tools are, by definition almost, a form of “stable, proven, reusable, and functional” entities, that are optimized for solving a problem or a set of problems, and did so over a period of time and a range of similar situations. But as technology advances so quickly, fewer perhaps than expected tools mature to be recognised, while ad-hoc solutions fly-by and evolve before a mould can cast them in iron.
That’s well thought out sfridman, great thing. Tools should be