This chapter is from the book
This chapter is from the book
This chapter is from the book
5.4 Pattern Profiles
Each of the patterns in this catalog is described using the same profile format and structure based on the following parts:
- Requirement
- Icon
- Summary
- Problem
- Solution
- Application
- Impacts
- Relationships
- Case Study Example
The following sections describe each part individually.
Requirement
This 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.
For example:
How can a service be designed to minimize the chances of capability logic deconstruction?
Note that the inside cover of this book lists all of the patterns together with their respective requirement statements.
Icon
Each pattern description is accompanied by an icon image that acts as a visual identifier.
An example of a pattern icon:
){kind=icon}
The icons are displayed together with the requirement statements in each pattern profile as well as on the inside book cover.
Summary
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, typically accompanied by a figure that further illustrates the “problem state.” It is this problem for which the pattern provides a solution. Problem descriptions may also include 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.
Note that these consequences are common but not necessarily predictable. For example, issues related to typical 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.
These diagrams are not exhaustive in that not all possible relationships a given design pattern can have are shown. Through the use of pattern relationship figures, this section merely highlights common relationships with an emphasis on how patterns support or depend on each other.
Case Study Example
Most pattern profiles conclude with a case study example that demonstrates the sample application of a pattern in relation to the storylines established in Chapter 2.