Patterns, Design Patterns, Architectural Patterns

Before writing about how an architect can achieve system's quality attributes, I thought it would be a good idea to dedicate a post about what a pattern is, and what is the difference between design and architectural patterns, for the sake of speaking the same ubiquitous language.

 I understand there are various definitions for these terms, but let's agree on theses for the scope of this blog.

An architect of a software system designs its architectural structures to solve a variety of design problems. These structures are based on one or more patterns.

So what is a pattern?

A pattern describes a particular recurring design problem that arises in specific design contexts, and represents a well-proven solution for the problem.

The solution is specified in terms of describing the roles of its constituent participants, their responsibilities and relationships, and how they collaborate.

Let's have a look at an example, and have a better understanding of problem, context and solution.

An Example: LAYER PATTERN

Context :Regardless of the interactions and coupling between different elements of a      software system, there is a need to develop and evolve them independently. Without a clear and reasoned separation of concerns, element interactions cannot be supported and elements cannot be independently developed.

Problem : Finding a design that partitions the application into meaningful, tangible elements that can be developed and deployed independently while preserving the architectural vision and addressing concerns such as performance, scalability, maintainability, and comprehensibility.

Solution :Define one or more layers for the software with each layer having a distinct and specific responsibility. Layers define a partitioning of software functionality according to a (sub)system-wide property so that each group of functionality is clearly encapsulated and can evolve independently. Functionality can be partitioned along various dimensions including abstraction, granularity, hardware distance, and rate of change. Layers are associated with each other via a one-way “allowed-to-use” relationship.

The Scope and Abstraction Level 

Here is where many people get confused: what is a design pattern, what is an architectural pattern, how are the different? 

To be honest with you I don't see much value in answering these questions, because after all you just pick a pattern that you need and use it you don't care about what category it fits in.

However because patterns cover various ranges of scale and are applied at various levels of abstraction, it is sometimes useful to broadly classify them as

• Architectural patterns - express a fundamental structural organisation schema for software systems. An architectural pattern provides a set of predefined [major architectural elements], specifies their responsibilities, and includes rules and guidelines for organising the relationships between them.

• Design patterns - provide a scheme for refining the [major architectural elements] of a software system, or the relationships between them. A design pattern describes a commonly recurring structure of communicating [elements] that solves a general design problem within a particular context.

• Idioms – are patterns specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

Note there is significant overlap and ambiguity in these definitions. Architectural design may incorporate any/all of the above types of patterns. 

If you are interested in patterns there is a very good book, I recommend:
 Pattern-Oriented Software Architecture which comes in five volumes.