I approached that from the opposite direction.

If you have a problem, there are several prerequisites for searching for a pattern to solve it:

* You should understand that you have a problem.

* You should believe that there is a realistic solution for it.

* You must be able to comprehend your issue and formulate it in the very terms that pattern authors or classifiers have used, probably decades ago.

* You should not restrict your search to your domain. For example, banking widely uses actors which originated in telecom.

* The application of the pattern you found should not be too expensive - you cannot rewrite your system from scratch if you find out that its architecture does not fit your needs.

* Finally, "no pattern is an island" - they multiply benefits when applied together. Your post-factum search for a solution of a specific problem is likely to miss the multipliers from related patterns of the pattern language.

Thus I believe that a pattern language is like a toolbox - you should know its contents before using it. And when there are hundreds of instruments in the box, you must organize them.

Even if I organize the tools "by size and shape", not by function, that still helps a lot - you are not going to open the section with large tools, like saws and shovels, if you want to drive a screw.

I try to build a way for easy grasping an overview of the hundred or two of architectural patterns so that a reader, when they get a real project, may remember some of the patterns and foresee their troubles months before those happen - just because they are aware of patterns that exist to solve those troubles, even and especially when they come from foreigh domains, as such a knowledge is absent from the community.