“As an architect you design for the present, with an awareness of the past, for a future which is essentially unknown.” — Normon Foster
You can think of architectural styles as a collection of principles that shape or govern the design of your application.
Many of the styles overlap and can be used in combination. Architectural styles tend to be tied both to the application type as well as to the point in time in which the application was developed.
I think the Mind Map helps show how you can group architectural styles based on types of problems they solve.
What is an Architectural Style?
An architectural style is 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.
According to Architectural Styles CS 377 Introduction to Software Engineering:
- Named collection. An architectural style is a named collection of architectural design decisions that are applicable in a given development context, constrain architectural design decisions that are specific to a particular system within that context, elicit beneficial qualities in each resulting system.
- Recurring organizational patterns and idioms. Established, shared understanding of common design forms. Mark of mature engineering field.
- Abstraction. Abstraction of recurring composition and interaction characteristics in a set of architectures.
According to Garlan and Shaw (January 1994, CMU-CS-94-166):
…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). Other constraints—say, having to do with execution semantics—might also be part of the style definition.” [David Garlan and Mary Shaw, January 1994, CMU-CS-94-166]
Benefits of Architectural Styles in Software Engineering
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.
How To Organize Architectural Styles in Software Engineering
Architectural styles can be organized by their key focus area.
The following table lists the major areas of focus and the corresponding architectural styles.
| Hot Spot | Architectural Styles |
|---|---|
| Communication | Service-Oriented Architecture(SOA) and/or Message Bus and/or Pipes and Filters |
| Deployment | Client/server or 3-Tier or N-Tier |
| Domain | Domain Model or Gateway |
| Interaction | Separated Presentation |
| Structure | Component-Based and/or Object-Oriented and/or Layered Architecture |
Key Architectural Styles in Software Engineering
The following table lists the common architectural styles described in this chapter.
It also contains a brief description of each style.
Later sections of this chapter contain more details of each style, as well as guidance to help you choose the appropriate ones for your application.
| Architectural Style | Description |
|---|---|
| Client-Server | Segregates the system into two applications, where the client makes a service request to the server. |
| Component-Based Architecture | Decomposes application design into reusable functional or logical components that are location-transparent and expose well-defined communication interfaces. |
| Layered Architecture | Partitions the concerns of the application into stacked groups (layers) such as presentation layer, business layer, data layer, and services layer. |
| Message-Bus | A software system that can receive and send messages that are based on a set of known formats, so that systems can communicate with each other without needing to know the actual recipient. |
| N-tier/3-tier | Segregates functionality into separate segments in much the same way as the layered style, but with each segment being a tier located on a physically separate computer. |
| Object-Oriented | An architectural style based on division of tasks for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object. |
| Separated Presentation | Separates the logic for managing user interaction from the user interface (UI) view and from the data with which the user works. |
| Service-Oriented Architecture (SOA) | Refers to Applications that expose and consume functionality as a service using contracts and messages. |
Architectural Style Combinations in in Software Engineering
The architecture of a software system is almost never limited to a single architectural style but is often a combination of architectural styles that form the complete system.
For example, you might have an SOA design composed of services developed using a layered architecture approach and an object-oriented architecture style.
The following examples show how combinations of some of these styles can be used to build applications:
Example 1 Architectural Style in Software Engineering
A combination of architecture styles will be useful if you are building a public-facing Web application. Employ effective separation of concerns by using the layered architecture style.
This will separate your presentation logic from your business logic and your data access logic.
Your organization’s security requirements might make you deploy the application using either the 3-tier deployment or a deployment of more than three tiers.
The presentation tier may be deployed in the perimeter network, which sits between an organization’s internal network and an external network.
On your presentation tier (Web server), you might decide on a separated presentation architecture style for your interaction model, such as MVC. From a communication standpoint between your Web server and application server, you might choose an SOA architecture style and implement message-based communication.
Example 2 Architectural Style in Software Engineering
If you are building a desktop application (Windows Forms application), you might prefer to have a client that sends a request to a program on the server.
Deploy the client and server using the client/server architecture style.
Use the component-based architecture to decompose the design further into independent components that expose the appropriate communication interfaces.
It is recommended that you use the object-oriented approach to improve reuse, testability, and flexibility.
Choosing an Architectural Style
There’s several factors that influence the architectural styles that you choose.
Some factors include the capacity of your organization for design and implementation; the capabilities and experience of developers; and the hardware and deployment scenarios available.
The architecture styles are related, so effectively you will be choosing a mix of architecture for your scenario. For example, when choosing a layered architecture, you may also choose to use an object-oriented or component-based design.
For more information, see Architecture Styles (Wikipedia)
You Might Also Like
Best Software Engineering Books of All Time
Architecture Styles, Patterns, and Metaphors
Architectural Patterns vs. System Metaphors
Incrementally Render the Solution
Personas at patterns & practices
Great article. One doubt. Being a solution architect for a while now, I have noticed that most of the architecture proposed for business solution primarily follows a Layered Architectural Style (at a high level). Further, if I ask any architect to propose a solution, 99% of them follows the same Layered Architectural Style. What are your thoughts?
Further, I am curious, does any one at Microsoft (including yourself) do any outside architecture mentoring?
@ Raju
Thank you.
On layers, just think of them as logical separation of concerns and to help enforce single responsibility. Also, remember they are fractal (e.g. a service can be made up of multiple layers). The common confusion around layers is mixing them with physical separation (tiers) or only using monolithic layers. Don’t use layers for layers sake, but many solutions are in fact layered architectures.
That’s a good question and I’m not sure what the normal channels are beyond what you find in books, forums, blogs and trade journals.