Master SOA Design
Pattern Catalog
|
|
"Introducing SOA Design Patterns", SOA World Magazine (PDF)
"The Case for Single-Purpose Services: Understanding the Non-Agnostic Context and a Strategy for Implementation", SOA Magazine (HTML)
"REST-Inspired SOA Design Patterns", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part I: A Comparison of Goals and Concepts", SOA Magazine (HTML)
"Service-Orientation and Object-Orientation Part II: A Comparison of Design Principles", SOA Magazine (HTML)
"Service Facade", InformIT (HTML)
"Non-Agnostic Context", InformIT (HTML)
"Domain Inventory", InformIT (HTML)
"Service Normalization", InformIT (HTML)
"Service Decomposition", InformIT (HTML)
"Canonical Schema", InformIT (HTML)
"Policy Centralization", InformIT (HTML)
|
|
|
What's a Compound Pattern?
|
Home >
What's a Compound Pattern?
|
A compound pattern is a coarse-grained pattern comprised of a set of finer-grained patterns. Singled out in this catalog are some of the more common and important combinations of the patterns, each of which is classified as a compound design pattern.
"Compound Pattern" vs." Composite Pattern"
A "composite" is generally something that is comprised of interconnected parts. For example, you could legitimately refer to a service composition as a composite of services because the individual parts need to be designed into an aggregate in order to act as a whole. A "compound," on the other hand, can simply be considered the result of combining a specific set of things together. A chemical compound consists of a combination of ingredients that result in something new when mixed together.
The patterns in this chapter are referred to as "compound patterns" because they document the effects of applying multiple patterns together. One of the most interesting parts of this exploration is that certain combinations of patterns result in design solutions that we are already familiar with, such as with the Enterprise Service Bus and Service Broker.
Compound Patterns and Pattern Relationships
Every pattern profile in the previous chapters includes a Relationships section that provides some insight into interpattern dependencies and how the application of one pattern can affect another.
Compound patterns are also about relationships, but in a different way. The patterns that comprise a compound pattern have a relationship with the compound pattern itself. Whether these patterns have dependencies with or impact each other is immaterial. When studying them as members of a compound pattern, we are only interested in the results of their combined application.
Joint Application vs. Coexistent Application
When we discuss the notion of combining patterns into compounds, it is important to clarify how patterns can be combined.
A compound pattern can represent a set of patterns that are applied together to a particular program or implementation in order to establish a specific set of design characteristics. This would be referred to as joint application.
Alternatively, the patterns that comprise a compound pattern can represent a set of related features provided by a particular program or environment. In this case, a coexistent application of patterns establishes a "solution environment" that may be realized by a combination of tools and technologies.
The notation used to express compound patterns comprised of patterns that are jointly applied versus those applied in a coexistent manner differs, as shown here:
Compound patterns comprised of patterns that are applied to coexist are expressed in a hierarchy, whereas those that are made up of patterns that are applied jointly are represented via a formula-style notation.
|
|
|
