Design fundamentals: Design pattern and design pattern language

Design pattern

We've established that service-orientation is a design paradigm comprised of a set of design principles, each of which provides a generalized rule or guideline for realizing certain design characteristics. The paradigm itself sounds pretty complete, and it actually is. However, to successfully apply it in the real world requires more than just a theoretical understanding of its principles.

Service designers will be regularly faced with obstacles and challenges when attempting to apply a design paradigm because the realization of desired design characteristics is frequently complicated by various factors, including:

• Constraints imposed by the technology being used to build and/or host the units of solution logic.
• Constraints imposed by technology or systems that reside alongside the deployed units of solution logic.
• Constraints imposed by the requirements and priorities of the project delivering the units of solution logic.

A design pattern describes a common problem and provides a corresponding solution (Figure 3.4). It essentially documents the solution in a generic template format so that it can be repeatedly applied. Knowledge of design patterns not only arms you with an understanding of the potential problems designs may be subjected to, it provides answers as to how these problems are best dealt with.

Figure 3.4

Patterns provide recommended solutions for common design problems. In this simplified example, a pattern suggests we reduce external access to a database to increase application autonomy.

Design patterns are born out of experience. Pioneers in any field had to undergo cycles of trial and error and by learning from what didn't work, approaches that finally did achieve their goals were developed. When a problem and its corresponding solution were identified as sufficiently common, the basis of a design pattern was formed. Design patterns can be further combined into compound patterns that solve larger problems and a series of patterns can form the basis of a pattern language, as explained next.

Design Pattern Language

The application of one design pattern can raise new issues or problems for which another pattern may be required. A collection of related patterns can establish a formalized expression of a design process whereby each addresses a primary decision point. Combining patterns in this manner forms the basis of a pattern language.

A pattern language is essentially comprised of a chain of related design patterns that establish a configurable sequence in which the patterns can be applied (Figure 3.5). Such a language provides a highly effective means of communicating fundamental aspects of a given design approach because it supplies detailed documentation of each major step in a design process that shapes the design characteristics of solution logic.

Figure 3.5

A sequence of related design patterns formalize the primary decision points of a design paradigm. In this example, the logic in application design B is decomposed as a result of one pattern, and then further decomposed as a result of another. Subsequent fundamental patterns continue to shape the logic.

Use the following table of contents to navigate to chapter excerpts.

SOA: Principles of Service Design
  Home: Service-oriented computing and SOA: Introduction
  1: Design fundamentals: Design characteristics
  2: Design fundamentals: Design principles and design paradigm
  3:Design fundamentals: Design pattern and design pattern language
  4:Design fundamentals: Design standard
  5:Design fundamentals: Best practices
  6:Introduction to service-oriented computing
  7:Service oriented architecture
  8:Service compositions
  9:Understanding service oriented computing elements
  10:Entity services
  11:Web services and service oriented computing
  12:Service inventory blueprints
  13:Service-oriented analysis and service modeling
  14:Service-oriented design
  15:Goals and benefits of service-oriented computing
  16:Increased intrinsic interoperability
  17:Increased federation
  18:Increased vendor diversification options
  19:Increased business and technology domain alignment
  20:Increased ROI
  21:Increased organizational agility
  22: Reduced IT burden