- •Chapter 1: What is Software Architecture? What is Software Architecture?
- •Why is Architecture Important?
- •The Goals of Architecture
- •The Architectural Landscape
- •The Principles of Architecture Design
- •Key Architecture Principles
- •Chapter 2: Key Principles of Software Architecture Overview
- •Key Design Principles
- •Determine the Application Type
- •Determine the Deployment Strategy
- •Determine the Appropriate Technologies
- •Key Design Considerations
- •Determine the Quality Attributes
- •Determine the Crosscutting Concerns
- •Chapter 3: Architectural Patterns and Styles
- •Contents
- •Overview
- •What Is An Architectural Style?
- •Summary of Key Architectural Styles
- •Combining Architectural Styles
- •Client/Server Architectural Style
- •Component-Based Architectural Style
- •Domain Driven Design Architectural Style
- •Layered Architectural Style
Summary of Key Architectural Styles
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. |
Domain Driven Design |
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. |
Combining Architectural Styles
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.
Many factors will influence the architectural styles you choose. These factors include the capacity of your organization for design and implementation; the capabilities and experience of your developers; and your infrastructure and organizational constraints. The following sections will help you to determine the appropriate styles for your applications.
