Patterns and the Real Life

In the last courses I gave on software architecture Í was using real life examples for some of the more complex patterns. Attendees told me that this approach had helped them significantly. Especially, patterns for concurrent and distributed systems are difficult to understand when introducing them in a pure software engineering context. Using real life examples for introducing patterns is not new. Several years ago Linda Rising initiated some OOPSLA workshops where participants had to provide real life examples for the patterns in the GoF and POSA books. I remember an asian guy whose wife was researching biochemistry and who came up with the example of a self healing organism in order to explain the Reflection pattern (POSA 1). Have you ever tried to understand the Reflection pattern without using a real life example? This is comparable to understanding quantum physics. Thus, the real life example approach should never be underestimated. I considered those real life example just a sort of entertainment for a long time but used them to explain to my wife and other people what the hell we were talking about in our books. In recent years, however, I recognized these real life pattern examples as a real value-add for pattern descriptions. I guess, the human brain requires some analogies to real world examples when processing abstract information (by the way, that is exactly the reason why quantum physics is almost impossible to understand, even after reading the Feynman lectures on physics).
Let me give an example. The Half-Sync/Half-Async pattern in POSA 2 deals with systems where asynchronous events are expected to trigger synchronous event processing in distributed systems. To separate both a queue is introduced by the pattern. This is exactly what will happen in a Burger restaurant. New customers will arrive and place their orders to an employee at the counter. This employee won't wait until all food items are ready but will tell some workers in the background to prepare the order, while taking the next order. This way, parallelism and thus efficiency is increasing. If these orders are processed in parallel, then their completion time is non-deterministic. How will the personal know which order is associated with which customer? This is where the ACT pattern is the only viable solution. ACT stands for Asynchronous Completion Token. Its solution structure is very simple: whenever an asynchronous operation is started, the operation is associated with a unique token either created by the requester or by the request processor. When the operation completes, the result is returned back together with the token. This way, the request and result can be easily associated with each other. In a Burger restaurant you'll get a number. As soon as your order is ready, someone will shout your number and you'll be able to pick up your food.
Needless to say that the same strategy works for Starbucks or beer gardens in Munich.
Hope, you'll see that these examples are particularly helpful to understand the patterns. Thus, my suggestion is to add real life examples to every pattern description, at least to those that are hard to understand. I am wondering whether we could also apply this idea in the opposite direction, i.e. taking real life examples for finding new software patterns.