Yes, that's right, patterns relate to other patterns. To work with design patterns, you need to understand these relationships. These relationships are especially important with respect to SOA because the scope of an SOA implementation tends to be larger than traditional applications. Therefore, SOA design patterns tend have a broader reach and, as a result, a greater impact.

Let's start with the basics and get back to how one pattern can relate to another. There are many different types of relationships, but two of the most important ones pertain to dependency and support.

In order to apply one pattern, you may be required to apply (or have already applied) another. That's a pretty straightforward dependency relationship, but it's still helpful to understand why the dependency exists. For example, in the SOA design pattern catalog there is a pattern called Logic Centralization. It essentially establishes a rule whereby, for any given reusable body of solution logic, only one official service can exist. This reduces the risk of redundancy and maximizes reuse potential among services within a given domain. It also forms the basis of Agnostic Context, a design pattern that is applied to an individual service in order to give it a multi-purpose functional scope (because it is "agnostic" to any logic that is limited to a single-purpose).

Agnostic Context and Logic Centralization share the common goal of fostering reuse within services. While Logic Centralization establishes distinct units of logic, Agnostic Context ensures that any units with reuse potential will be limited to multi-purpose logic only. This way, they become purely reusable services.

In short, you could make a case that Agnostic Context is dependent on Logic Centralization because without centralizing distinct bodies of logic, it would be difficult to segment them into agnostic units. It wouldn't make much sense to apply Agnostic Context until after the Logic Centralization pattern has been applied.

The other type of relationship we mentioned is where the application of one pattern supports another. So unlike the dependency relationship, there is no direct reliance in this case, which means that these types of relationships are easy to miss (as are their benefits). A supportive relationship simply means that one pattern helps realize the goals or ultimate purpose of another.