What's the difference between Architectural Pa

问题:

In Software Architecture - Foundations, Theory and Practice, I can find definitions for both. The problem is that I don't get what each one of them means in plain English:

Architectural Pattern

An Architectural Pattern is a named collection of architectural design decisions that are applicable to a recurring design problem parameterized to account for different software development contexts in which that problem appears.

Architectural Style

An Architectural Style is a named collection of architectural design decisions that (1) are applicable in a given development context, (2) constrain architectural design decisions that are specific to a particular system within that context, and (3) elicit beneficial qualities in each resulting system.

What does each one mean and what are the differences between them?

回答1:

An Architectural Pattern is a way of solving a recurring architectural problem. MVC, for instance, solves the problem of separating the UI from the model. Sensor-Controller-Actuator, is a pattern that will help you with the problem of actuating in face of several input senses.

An Architectural Style, on the other hand, is just a name given to a recurrent architectural design. Contrary to a pattern, it doesn't exist to "solve" a problem.

Pipe&filter doesn't solve any specific problem, it's just a way of organizing your code. Client/server, Main program & subroutine and Abstract Data Types / OO, the same.

Also, a single architecture can contain several architectural styles, and each architectural style can make use of several architectural patterns.

回答2:

Frankly, i have always considered both these terms to be synonymous! And layman (relatively speaking) literature definitely treats them as such. Refer MSDN or Wikipedia

However, your question intrigued me a bit so i did a bit more digging and frankly...i couldnt find much except for a reference to A Practical Guide to Enterprise Architecture (The Coad Series), from which i quote :-

An architectural style (Base et al. 1997) and an architectural pattern 
(Buschmann et al. 1996) are essentially synonymous. 

Based on some more googling, this is what i think might be one possible way to differentiate the two

• An architectural style is a conceptual way of how the system will be created / will work
• An architectural pattern describes a solution for implementing a style at the level of subsystems or modules and their relationships.

How an architectural pattern will differ from a Design pattern i.e Adapter, observer is basically by the level of Granularity at which they are applied (I know this isnt part of the question but its related, i think)

回答3:

In very simple words:

• An architectural style

  Is a concept, theory (and how it's implemented it is up to you). It can also apply to outside of the software world.

  In example: REST (Representational State Transfer) is an architectural style built on certain principles using the current “Web” fundamentals.

• An architectural patterns

  Describes a solution at the software system (or module) level. In other words how it interacts each other e.g. view with model, and model with controller.

• A design patterns

  Is a solution at the core level, it talks about classes, functions and how actually the logic flows.

回答4:

Architectural Style is abstract i.e. conceptual.

+---------------+--------------------------------------------------------+
|   Category    |                  Architecture styles                   |
+---------------+--------------------------------------------------------+
| Communication | SOA, ROA, Message Bus                                  |
| Deployment    | Client/Server                                          |
| Domain        | Domain Driven Design,Monolithic application            |
| Structure     | Component-Based, Object-Oriented, Layered, Plug-ins    |
+---------------+--------------------------------------------------------+

An Architectural Pattern is concrete i.e. implementation of an Architectural Style.

• For example: 3-tier, N-tier, MVC, REST

A Design pattern is a general reusable solution to a commonly occurring problem in software design at architectural level.

• For example: Factory, Singleton, Prototype.

Analogy: Temples architecture style for different religions:

回答5:

In my view, patterns and architectural styles are complementary mechanisms for encapsulating design expertise. An architectural style provides a collection of building block design elements, rules and constraints for composing the building blocks, and tools for analyzing and manipulating designs created in the style. Styles generally provide guidance and analysis for building a broad class of architectures in a specific domain whereas patterns focus on solving smaller, more specific problems within a given style (or perhaps multiple styles).

回答6:

For Architectural Patterns think specific ways to style your code as described by the GoF like; Adapter, Strategy, Builder, Mediator, etc

For Architectural Style think overall system; I.E., using MVC for presentation, DDD to model the business layer, WCF (if you're into .NET) for Interop, SOA for integration, etc.

回答7:

Architectural design patterns are more domain specific where are architectural styles are more generic and usable in wide range of applications. Because of this architectural patterns requires more domain knowledge.

回答8:

Architectural Patterns – define a general set of element types and their interactions. Examples of Architectural Patterns include Pipes and Filters, Model–View–Controller, and Reflection.

Architectural Style – the term was coined by Garlan and Shaw, it is an idiomatic pattern of system organization. For example, a client–server system is an architectural style.

p.s : Many of the original architectural styles have been reformulated as patterns.

回答9:

Architecture pattern: context + problem -> solution

Architecture style: solution part of architecture pattern

So architecture style is analogous to the solution part of the architecture pattern. It's often used in books dealing with architecture documentation where the focus is on the solution and not how the context and problem came about.