Software Architecture styles

July 14, 2014
Why Software architecture

This chapter describes and discusses high level patterns and principles commonly used for applications today. These are often referred to as the architectural styles, and include patterns such as client/server, layered architecture, component-based architecture, message bus architecture, and service-oriented architecture (SOA). For each style, you will find an overview, key principles, major benefits, and information that will help you choose the appropriate architectural styles for your application. It is important to understand that the styles describe different aspects of applications. For example, some architectural styles describe deployment patterns, some describe structure and design issues, and others describe communication factors. Therefore, a typical application will usually use a combination of more than one of the styles described in this chapter.

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:

“&#2026a; 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, see "An Introduction to Software Architecture" at ]

An understanding of architectural styles provides several benefits. The most important benefit is that they provide a common language. They also provide opportunities for conversations that are technology agnostic. This facilitates a higher level of conversation that is inclusive of patterns and principles, without getting into specifics. For example, by using architecture styles, you can talk about client/server versus n-tier. Architectural styles can be organized by their key focus area. The following table lists the major areas of focus and the corresponding architectural styles.

Category

Architecture styles

Communication

Service-Oriented Architecture (SOA), Message Bus

Deployment

Client/Server, N-Tier, 3-Tier

Domain

Domain Driven Design

Structure

Component-Based, Object-Oriented, Layered Architecture

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.

Architecture style

Description

Client/Server

Segregates the system into two applications, where the client makes requests to the server. In many cases, the server is a database with application logic represented as stored procedures.

Component-Based Architecture

Decomposes application design into reusable functional or logical components that expose well-defined communication interfaces.

An object-oriented architectural style focused on modeling a business domain and defining business objects based on entities within the business domain.

Layered Architecture

Partitions the concerns of the application into stacked groups (layers).

Message Bus

An architecture style that prescribes use of a software system that can receive and send messages using one or more communication channels, so that applications can interact without needing to know specific details about each other.

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

A design paradigm based on division of responsibilities for an application or system into individual reusable and self-sufficient objects, each containing the data and the behavior relevant to the object.

Service-Oriented Architecture (SOA)

Refers to applications that expose and consume functionality as a service using contracts and messages.

The architecture of a software system is almost never limited to a single architectural style, but is often a combination of architectural styles that make up the complete system. For example, you might have a SOA design composed of services developed using a layered architecture approach and an object-oriented architecture style.

A combination of architecture styles is also useful if you are building a public facing Web application, where you can achieve 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 force you to deploy the application using either the 3-tier deployment approach, or a deployment of more than three tiers. The presentation tier may be deployed to the perimeter network, which sits between an organization's internal network and an external network. On your presentation tier, you may decide to use a separated presentation pattern (a type of layered design style), such as Model-View-Controller (MVC), for your interaction model. You might also choose a SOA architecture style, and implement message-based communication, between your Web server and application server.

If you are building a desktop application, you may have a client that sends requests to a program on the server. In this case, you might deploy the client and server using the client/server architecture style, and use the component-based architecture style to decompose the design further into independent components that expose the appropriate communication interfaces. Using the object-oriented design approach for these components will improve reuse, testability, and flexibility.

Source: msdn.microsoft.com
RELATED VIDEO
Loading AEC Architecture Wall Styles in Caddie .dwg software
Loading AEC Architecture Wall Styles in Caddie .dwg software
AEC Slab edge styles in Caddie AEC Architecture .dwg software
AEC Slab edge styles in Caddie AEC Architecture .dwg software
Architectural Styles in Software Architecture
Architectural Styles in Software Architecture
RELATED FACTS
Share this Post