Architectural Style in a nutshell
What is an architectural style? According to App Arch Guide, an architectural style is?
According to App Arch Guide 2.0 (Microsoft patterns&practices), Chapter 6
A set of principles. You can think of it as a coarse-grained pattern that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems.
An architectural style, sometimes called an architectural pattern, is a set of principles — a coarse grained pattern that provides an abstract framework for a family of systems. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently recurring problems. You can think of architecture styles and patterns as sets of principles that shape an application. Garlan and Shaw define an architectural style as: “a family of systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles).1
Following are key points of Architectural Style:-
- An architectural style is a central, organizing concept for a system.
- An architectural pattern describes a coarse-grained solution at the level of subsystems or modules and their relationships.
- A system metaphor is more conceptual and it relates more to a real-world concept over a software engineering concept.
Architectural styles provide several benefits. The most important of these benefits is that they provide a common language. Another benefit is that they provide a way to have a conversation that is technology-agnostic. This allows you to facilitate a higher level of conversation that is inclusive of patterns and principles, without getting into the specifics. For example, by using architecture styles, you can talk about client-server versus N-Tier.
According to Architectural Styles CS 377 Introduction to Software Engineering:
- Design Reuse. Well-understood solutions applied to new problems.
- Code reuse. Shared implementations of invariant aspects of a style.
- Understandability of system organization. A phrase such as ‘client-server” conveys a lot of information.
- Interoperability. Supported by style standardization.
- Style-specific analysis. Enabled by the constrained design space.
- Visualizations. Style-specific descriptions matching engineer’s mental models.
The authors of the guide list a number of architectural styles:
Each of those architectural styles are applied to specific areas of interest:
J.D. Meier, summarizing a few key points from the book A Practical Guide to Enterprise Architecture by James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo, noted a subtle difference between architectural styles and patterns:
- An architectural style is a central, organizing concept for a system.
- An architectural pattern describes a coarse-grained solution at the level of subsystems or modules and their relationships.
- A system metaphor is more conceptual and it relates more to a real-world concept over a software engineering concept.
David Calvert made in 1996 a partial list of architecture Data flow Systems — Batch sequential, Pipes and filters.
- Call-and-return systems — Main program and subroutines, OO systems, Hierarchical layers.
- Independent components — Communicating processes, Event Systems.
- Virtual Machines — Interpreters, Rule-based systems.
- Data-centered systems (repositories) — Databases, Hypertext system, Blackboards.
Scope of Software Architecture
Opinions vary as to the scope of software architectures:
- Overall, macroscopic system structure; this refers to architecture as a higher level abstraction of a software system that consists of a collection of computational components together with connectors that describe the interaction between these components.
- The important stuff — whatever that is; this refers to the fact that software architects should concern themselves with those decisions that have high impact on the system and its stakeholders.
- That which is fundamental to understanding a system in its environment”
- Things that people perceive as hard to change; since designing the architecture takes place at the beginning of a software system’s lifecycle, the architect should focus on decisions that “have to” be right the first time. Following this line of thought, architectural design issues may become non-architectural once their irreversibility can be overcome.
- A set of architectural design decisions; software architecture should not be considered merely a set of models or structures, but should include the decisions that lead to these particular structures, and the rationale behind them. This insight has led to substantial research into software architecture knowledge management.
- There is no sharp distinction between software architecture versus design and requirements engineering. They are all part of a “chain of intentionality” from high-level intentions to low-level details.
Benefits of Architectural Styles
Architectural styles provide several benefits. The most important of these benefits is that they provide a common language. Another benefit is that they provide a way to have a conversation that is technology-agnostic. This allows you to facilitate a higher level of conversation that is inclusive of patterns and principles, without getting into the specifics. For example, by using architecture styles, you can talk about client-server versus N-Tier.
According to Architectural Styles CS 377 Introduction to Software Engineering:
- Design Reuse. Well-understood solutions applied to new problems.
- Code reuse. Shared implementations of invariant aspects of a style.
- Understandability of system organization. A phrase such as ‘client-server” conveys a lot of information.
- Interoperability. Supported by style standardization.
- Style-specific analysis. Enabled by the constrained design space.
- Visualizations. Style-specific descriptions matching engineer’s mental models.
Other more modern styles/patterns are: Plugin, Peer-to-Peer, Shared Nothing Architecture, Representational State Transfer (REST), Front-end and back-end. There is a more complete list on Wikipedia.
Thanks for reading. I wish you have a happy reading.
Note:- I have took an Effort to summarise from link given above .
