What reminded me of this issue is a post concerning Enterprise Integration Patterns. The author, Mark Carlson, states:
So far, I've found that many of the "patterns" in the book fall into what I would have normally called definitions. Examples of these foundational patterns include Message (66), Message Channel (60), Message Endpoints (95), Point-to-Point Channels (103), Publish-Subscribe Channels (106) and others.
However, I don't want to pick on Mark. Since Gregor and I started working on the book, I've heard several people express that concern. I'm just quoting Mark as an example.
This debate has occurred for years, and I probably won't settle it today, but here's my $0.02 worth.
Not too surprisingly, I contend that these items are patterns, not just definitions. What's the difference? A definition tells you what an item is. A pattern tells you not only what it is, but what to use it for and how. The definition of a Message Channel tells you that it transmits messages from senders to receivers. OK, that's nice to know, but so what? The Message Channel pattern tells you when to use separate channels, so that you start to get some idea of how many you need and why you can't use just one. The definition of a Message tells you that it contains data to be transmitted between a sender and receiver. The Message pattern tells you why you can't simply dump a data structure or a bunch of bytes into a message channel and hope to have it come out the other end properly, how you need to design your messages to have a format that the sender and receiver agree on. As pattern documents, these sets of prose should (and hopefully do) have some Therefore, BOOM! to them, which helps you understand why the problem is difficult to solve and then solves it anyway.
I often feel like one person's pattern is another person's "obvious solution that we use all the time." This discussion comes up a lot at PLoP. The sentiment Mark expressed seems similar; one person's pattern is another person's "definition of the term." It probably seems more like a definition to readers who already know the term, but it's new news to readers who are still learning these terms.
If it's a language or product feature, is it still a pattern? The JMS names for Message Channel and Message are Destination and Message. A Point-to-Point Channel is what JMS calls a Queue, as do most messaging products such as WebSphere MQ. But these are still patterns because you need to know not just that they are features, but when to use those features. Sean Neville addresses this issue when he says, "When a pattern's tactic or implementation strategy is standardized, the pattern does not wane in usefulness, replaced by that standard; instead, quite the opposite occurs." A pattern that is a product feature is a pattern that's much easier to apply!
Patterns are decisions: What should you do and when should you do it? Many definitions do not make good patterns because they don't represent decisions. As discussed, Message is a pattern because you need to decide when to use one and how many. Our pattern document explains that a message is composed of two parts, a header and a body, thereby defining what those terms mean. Header and body are not good patterns because you don't decide when to use them; you get them whenever you decide to use a message. OTOH, a good pattern might be "header field," because sometimes you have to decide whether and how to put a value in the message header. You might need your own custom header fields for a request ID to be used as a Correlation Identifier, or as a flag to be used by a Content-Based Router. Notice that I'm not talking so much about what a header field is--that's a definition; I'm talking about what a header field is used for--that's a pattern.
So don't think of patterns as definitions. A pattern document that just defines a term shouldn't call itself a pattern. Think of them as the fundamental building blocks of a pattern language, the parts we've all got to agree on before we can get to the harder stuff.
BTW, I wonder whatever happened to the webMethods paper Mark was working on? It sounds interesting; I'd like to take a look at it.