Home > Overview > Pattern Profiles

Pattern Profiles

In addition to the pattern name and the name of its contributor(s), each of the patterns in this catalog is described using a consistent profile format and structure based on the following parts:

  • Requirement
  • Icon
  • Summary Table
  • Principles
  • Architecture
  • Problem
  • Solution
  • Application
  • Impacts
  • Relationships
  • Case Study Example

The following sections describe each part of a pattern profile individually. Note that as per Prentice Hall publishing requirements, only the Requirement, Icon, Summary Table, a sample figure, and links to related patterns are published for each pattern on this Web site for patterns that are part of the master catalog. The detailed sections, case study examples, relationship diagrams, and additional supplementary content are provided in the book. Because candidate patterns are published for review purposes, more detailed information is sometimes made available.

Requirement

A requirement is a concise, single-sentence statement that presents the fundamental requirement addressed by the pattern in the form of a question. Every pattern description begins with this statement.

An example of a requirement statement:

How can a service be designed to minimize the chances of capability logic deconstruction?

Icon

Each pattern description is accompanied by an icon image that acts as a visual identifier.

An example of a pattern icon:

img

The icons are displayed together with the requirement statements in each pattern profile as well as on the inside book cover.

Summary Table

Following the requirement statement, a summary table is displayed, comprised of statements that collectively provide a concise synopsis of the pattern for quick reference purposes.

The following parts of the profile are summarized in this table:

  • Problem
  • Solution
  • Application
  • Impacts

Additionally, the profile table provides references to related service-orientation design principles and service-oriented architectural types via the following sections:

  • Principles
  • Architecture

The parts of the pattern description not represented in the summary table are the Relationships and Case Study Example sections.

Problem

The issue causing a problem and the effects of the problem are described in this section, which is typically accompanied by a figure that further illustrates the "problem state." It is this problem for which the pattern is expected to provide a solution. Often included with problem descriptions are common circumstances that can lead to the problem (also known as "forces").

Solution

This represents the design solution proposed by the pattern to solve the problem and fulfill the requirement. Often the solution is a short statement followed by a diagram that concisely communicates the final solution state. "How-to" details are not provided in this section but are instead located in the Application section.

Application

This part is dedicated to describing how the pattern can be applied. In can include guidelines, implementation details, and sometimes even a suggested process.

Impacts

Most patterns come with trade-offs. This section highlights common consequences, costs, and requirements associated with the application of a pattern and may also provide alternatives that can be considered.

Note that these consequences are common but not necessarily predictable. For example, issues related to common performance requirements are often raised; however, these issues may not impact an environment with an already highly scalable infrastructure.

Relationships

The use of design patterns can tie into all aspects of design and architecture. It is important to understand the requirements and dependencies a pattern may have and the effects of its application upon other patterns. This section is therefore dedicated to documenting key pattern relationships. On this Web site pattern relationships are highlighted via the Related Patterns section on the bottom of each pattern page.

The content in this section is not exhaustive in that not all possible relationships a given design pattern can have are covered. This section highlights key relationships only, with an emphasis on how patterns support or depend on each other.

For an example of a relationship figure, see the Pattern Notation page.

Case Study Example

Almost all pattern profiles conclude with a case study example that demonstrates the sample application of a pattern in relation to the overall case study storylines.