Explained - Architectural Styles
J.D. Meier, Alex Homer,
Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
- Learn key architectural styles in common use today.
- Learn about the scenarios, key principles, and benefits of each style.
- Learn how to choose an appropriate architectural style for your application.
This chapter describes and discusses the different architectural styles commonly used for applications, such as client/server, layered architecture, component-based architecture, message-bus architecture, and service-oriented architecture. For each style, it
lists the key principles and the major benefits, and shows examples of its use.
Over the years architecture has evolved with technology advancement and better understanding of software development. In the very early days software applications were large monolithic applications using procedural code. These monolithic applications were difficult
to maintain and understand. This fueled the need for structuring the applications by breaking them into logical functional units, which lead to modular designs that evolved into object-based and object-oriented architectures.
- Client-Server architecture. The logical progression was to leverage resources, such as database on shared machine in an enterprise. This evolved into Client-Server architecture, where group of functionality or a resource such as database was deployed
on a common machine (server) and accessed by other machines (client) in the enterprise.
- 3-Tier Architecture. With internet era, web applications started becoming an important class of applications which helped in evolving the 3-Tier architecture. The main driving force was to create an environment agnostic user interface, which can
call into applications deployed to servers in an organization. So in simple words it was User Interface + Client-Server.
- N-Tier Architecture. As the web applications started opening to a wider audience, security, performance and scalability became prime concerns which led to the evolution of N-Tier architecture, where the application functionality in the server environment
was split into various layers and deployed on various tiers to improve security and performance of the applications.
- Distributed Objects. The evolution of N-Tier architecture was driving factor for Distributed Objects, as it was the enabler for grouping functionality into objects that could be deployed to remote machines and accessed by distributed clients.
- Component-Based Architecture. Thinking in terms of objects posed the same maintainability issues and lack of understanding with complex object-based applications. Also, the objects could not be re-used easily, this lead to a component based architecture
where the system is segregated into functional or logical independent deployable components. Components have well defined interfaces and provide a specific functionality or a “service”. To support N-Tier architecture the components evolved into distributed
- Service Oriented Architecture. With onset of technology advancement and need for collaboration across organization forced evolution component based architecture to service oriented architecture.
- Applications as services and applications that use services. In today’s world services have become backbone of many applications and are used in applications such as Business Process Management (BPM), Composition / Aggregation, Mash Ups, RIA, Software
as a Service (Saas).
Following table walks you through key architectures.
||The system is segregated into functional or logical independent deployable components. The components have well defined interfaces and provide a specific functionality or a “service”.
||The application or system is segregated to run on multiple machines communicating with each other over the network by exchanging messages or using remote procedure calls. Following are various variants of distributed architecture Client / Server, n-Tier/
3 –Tier architecture.
||The system or application is defined as a set of objects used to support application functionality. The objects contain both data and behavior and provide an interface for interacting with them. The complete system is seen as objects and interactions between
||Components with similar functionality are grouped together to form logical layers. The logical layers have a clear relationship defined with other layers in the system. Layered architecture is an example of Hierarchical architecture.
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. Each style defines a set of rules that specify the kinds of components you can use to assemble a system,
the kinds of relationships used in their assembly, constraints on the way they are assembled, and assumptions about the meaning of how you put them together. An architectural style improves partitioning and promotes design reuse by providing solutions to frequently
Summary of Key Architecture Styles
||Segregates the system into two computer programs in which one program, the client, makes a service request from another program, the server.
||Decomposes application design into functional or logical re-usable components that expose well-defined communication interfaces.
||Segregates the system into groups of similar functionality into layers and hierarchical distribution of roles and responsibilities to each layer.
||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 having to know the actual recipient.
||Separates the logic for managing user interaction from the user interface view and from the data that the user works with.
||Separates 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 Architecture (OO)
||A programming 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.
|Service-Oriented Architecture (SOA)
||Applications that expose and consume functionality as a service with contracts and messages.
Organizing the Architecture Styles
The architecture styles can be organized by the key focus area, following table list various focus areas and corresponding architectural styles available.
||Client-Server, N-Tier, 3-Tier
||Object-Oriented, Component-Based, Layered Architecture
||Gateway, Domain Model
||Service-Oriented Architecture (SOA), Message Bus, Pipes and Filters
The client-server software architecture model distinguishes client systems from server systems, which communicate over a computer network. A client-server application is a distributed system comprising of both client and server software. A client software process
may initiate a communication session, while the server waits for requests from any client.
Client/server describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server. Standard networked functions such as email exchange, web access and database access, are based
on the client/server model. For example, a web browser is a client program at the user computer that may access information at any web server in the world.
The client/server architectural style has the following identifying characteristics:
- It is a style for defining distributed systems.
- It involves a separate client and server system, and a connecting network.
- It describes the relationship between the client and one or more servers, with the client making requests to the server, and the server sending responses.
- It can use a range of protocols and data formats to communicate information.
The key principles of the client/server architectural style are the following:
- The client initiates one or more requests, waits for replies, and processes the replies on receipt.
- The client usually connects to one or only a small number of servers at any one time.
- The client interacts directly with the user, perhaps using a graphical UI.
- The server does not initiate any requests.
- The server responds to network requests from connected clients.
- The server typically authorizes the user and then carries out processing required to generate the result.
- The server transfers the data to the client as the response.
The main benefits of the client/server architectural style are the following:
- Higher security. All the data is stored on the server, which generally have far greater security control than most clients.
- Centralized data access. Since data is stored only in the server, access and updates to the data are far easier to administer than other models.
- Ease of maintenance. The architecture enables the roles and responsibilities of a computing system to be distributed among several independent computers (servers) that are known to each other only through a network. This ensures that a client remains
unaware and unaffected by a server repair, upgrade or relocation.
Some examples of the client/server architectural style are the following:
- Web browser based programs running on the Internet or an intranet.
- Windows Forms applications that access back-end services.
- Applications that access remote data stores, such as email readers, FTP clients, and database query tools.
- Tools and utilities that manipulate remote systems, such as system management tools and network monitoring tools.
Variations on the client/server style include:
- Client-Queue-Client Systems. Clients can read data from and send data to a server that acts simply as a queue to store the data. This allows clients to distribute and synchronize files and information.
- Peer-to-peer (P2P) Applications. Developed from the Client-Queue-Client style, the P2P style allows the client and server to swap their roles in order to distribute and synchronize files and information across multiple clients.
- Application Servers. A specialized client/server architectural style where the server hosts and executes applications that a thin client controls through specialized client-installed software.
Component-based architecture describes a software engineering approach to system design and development. It focuses on the decomposition of design into functional or logical components that expose well-defined communication interfaces. This provides a higher
level of abstraction than object-oriented design principles, and does not focus on object-specific issues such as communication protocols and shared state.
The component-based architectural style has the following identifying characteristics:
- It is a style for designing applications made up of individual components. Component-based applications may be client/server, layered, SOA, or any other common application design style.
- It places the emphasis on decomposing systems into functional or logical components that have well-defined interfaces.
- It defines a design approach that uses discrete components, which communicate through interfaces containing methods, events, and properties.
- It is often referred to as "component-based software engineering".
A component is a software object specifically designed to achieve a certain purpose. The key principles when designing components are that they should be:
- Reusable. Components are usually designed to be reused in different scenarios in different applications. They do not have to be general purpose - in some cases, you may need to create components that are specific to one focused task, but the component
should still be reusable in situations that require the same task.
- Not context-specific. Information specific to one scenario, such as state data, should be passed to the component instead of being included in the component, so that a component can operate in different environments and contexts.
- Composable. It should be possible to use the component with other components to assemble larger sections of an application.
- Encapsulated. It should expose interfaces that allow code to use its functionality, and not reveal internals details of the processes or any internal variables or state.
- Independent. It should be possible to deploy the component in any appropriate environment with minimal or no dependencies on other components or the environment. It should also be independently versioned to allow updates that do not affect other
components or systems.
The main benefits of the component-based architectural style are the following:
- Ease of deployment. As new compatible versions become available, you can replace existing versions with no impact on the other components or the system as a whole.
- Reduced cost. The use of third-party components allows you to spread the cost of development and maintenance.
- Flexibility. Components can be written in any source code language compatible with the runtime environment. This means that developers can use familiar languages and techniques.
- Ease of development. They implement a known interface to provide defined functionality, allowing development without concern on the impact of other parts of the system.
- Reusable. This means that they can be used to spread the development and maintenance code over several applications or systems.
Many applications in use today use the component-based style, although some components may communicate using a message-based interface instead of direct communication through methods, events, and properties. Common types of components used in applications include:
- User interface components, such as grids and buttons, often referred to as "controls".
- Business logic components that apply business rules to a process.
- Data access components that interact with a data store such as a relational database.
- Helper components that exposes a specific subset of functions used in other components.
The layered model of software architecture provides a highly effective separation of concerns, helping architects to organize their decision-making process and providing focus for action. Layered architecture focuses on a hierarchical distribution of roles
and responsibilities. The role indicates the mode and type of interaction with other layers and responsibility indicates the functionality being addressed. For example, a typical web application design comprises of the Presentation Layer (functionality related
to UI), Business Layer (business rules processing) and Data Access layer (functionality related to data access). Separating functionality into logical layers provides clearly defined boundaries for managing security, more opportunities for reuse of components,
simplifies testing and maintenance, and identifies intra-application communication requirements.
The layered architectural style has the following identifying characteristics:
- It is a style for designing applications that separate the user interface, business processing, and data access tasks into three or more layers.
- It describes decomposition of services so that the majority of interactions occur only between neighboring layers.
- The layers may reside on the same physical computer (the same tier), or may be distributed over separate computers.
- The components in each layer communicate with components in other layers through well-defined interfaces.
- Layers on the same physical tier may communicate using direct in-process techniques (such as calling methods). Layers in separate physical tiers communicate using a message-based approach.
In the layered style, the system is divided into separate sections to make design, development, and maintenance easier, and to improve testability. Common principles when designing using this style or architecture are:
- Clearly defined context. Analysis identifies the main components required for the system, and determines the relationship and interactions between them.
- Abstraction. The design should be abstract enough to view the model as a whole, but detailed enough to understand the relationships between the layers.
- Encapsulation. The design should not make assumptions about data types, methods and properties, and implementation.
- Clearly defined functional layers. The design should clearly define the separation between functionality in each layer. Lower layers for example Business layers and data access layers, expose services and implement interfaces. Upper layers for example
service layer and presentation layer, implement user interfaces or application interfaces, and maintain state. Upper layers send commands to lower layers, and data flows both up and down through the layers.
- High cohesion. Each layer should contain functionality directly related to the tasks of that layer..
- Loose coupling. Lower layers have no dependencies on higher layers, allowing them to be reusable in other scenarios. Communication between layers is based on abstraction that provides loose coupling between layers. Abstraction can be implemented
using interfaces, common base classes, message-based interaction, and common object oriented patterns.
The main benefits of the layered architectural style are the following:
- Maintenance of and enhancements to the solution are easier due to the low coupling between layers, high cohesion between the layers, and the ability to switch out varying implementations of the layer interfaces.
- Other solutions should be able to reuse functionality exposed by the various layers, especially if the layer interfaces are designed with reuse in mind.
- Distributed development is easier if the work can be distributed at layer boundaries.
- Distributing the layers over multiple physical tiers can improve scalability, fault-tolerance, and performance.
- Testability benefits from having well-defined layer interfaces as well as the ability to switch out various implementations of the layer interfaces.
- It removes the requirement to consider hardware and deployment issues and external interface dependencies.
- Layers allows changing the abstraction level - since layers are hierarchical in nature, moving through the layer "stack" you can increase or decrease the level of abstraction you use.
Common types of layered applications include:
- Line of Business (LOB) applications such as accounting and customer management systems.
- Applications that display and manipulate data of all kinds.
- Enterprise Web-based applications and Web sites.
- Enterprise Desktop or Smart clients with centralized application servers for business logic.
- Enterprise Mobile applications that connect to centralized application servers
Message-bus architecture describes the principle of using 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 having to know the actual recipient. The message-bus
system will route messages to the appropriate recipient, or to more than one recipient, based on the message content or on instructions provided in other ways (commonly through some implementation of the Publish/Subscribe design pattern). The messages may
be exposed using Web services, but this is not a requirements. Message-bus systems may receive and send messages in text formats, as email messages, or as messages in a message queuing system.
The message-bus architectural style has the following identifying characteristics:
- It is a style for designing applications where interaction between applications is accomplished by passing messages over a common bus.
- Many designs use a message-oriented-middleware approach where a message router is used to dispatch messages to appropriate components.
- It is often implemented using a messaging system, such as Microsoft Message Queue.
- It consists of individual applications that communicate using common schemas and a shared infrastructure for sending and receiving messages.
- The Publish/Subscribe pattern is often used to support interaction between applications that use the message bus.
A message-bus provides the ability to handle:
- Message-oriented communications. All communication between applications is based on messages that use a common schema.
- Complex processing logic. Instead of creating large complex applications you can create a set of smaller applications that support specific tasks. When combined these tasks can be used to support complex operations.
- Modifications to processing logic. Since interaction with the bus is based on common schemas and commands you can insert or remove applications from the bus to change the logic used to process messages.
- Integration with different environments. By using a message-based communication model based on common standards you can have applications developed for different environments, such as Microsoft .NET and Java based environments.
The main benefits of the message-based architectural style are the following:
- Expandability. Applications can be added to or removed from the bus without having an impact on the existing applications.
- Flexibility. Upgrading the bus interface will have no impact to existing applications as long as compatibility is maintained for existing messages.
- Low complexity. Application complexity is reduced because each application only needs to know how to communicate with the bus.
- Higher performance. Performance is improved because there are no intermediaries between the communicating applications. The only limitation is how fast the message bus can move messages.
- Scalability. Multiple instances of the same application can be attached to a bus in order to handle multiple requests at the same time.
- Each application only needs to support a single connection to the message bus instead of multiple connections to other applications.
- Each application only needs to support a single connection to the message bus instead of multiple connections to other applications.
Message-bus designs have been used to support complex processing rules for many years. It provides a pluggable architecture that allows you to insert applications into the process or improve scalability by attaching several instances of the same application
to the bus.
Variations on the message bus style include:
- Enterprise Service Bus (ESB). Based on message-bus designs, an ESB uses services for communication between the bus and components attached to the bus. As with a message-bus design, message routers are typically used to manage the routing of logic
through components attached to the bus. In addition, an ESB will usually provide services that transform messages from one format to another, allowing clients that use incompatible message formats to communicate with each other
- Internet Service Bus (ISB). Similar to an enterprise service bus with applications hosted in the cloud instead of an enterprise network. A core concept around ISB is the use of Uniform Resource Identifiers (URI) and policies to control the routing
of logic through applications and services in the cloud.
Model View Controller (MVC)
Model-View-Controller represents a style used for handling requests or user actions, and manipulating the UI and the application data. The MVC pattern separate UI processing into three distinct roles called the Model, the View, and the Controller.
An MVC architectural style has the following identifying characteristics:
- It is a style for designing applications based on well-known design patterns.
- It separates the logic for managing user interaction from the user interface view and from the data that the user works with.
- It allows graphical designers to create a user interface while developers generate the code to drive it.
- It provides support for improved testability. By dividing the functionality into separate roles you have increased opportunity to test the behavior of individual roles.
The key principles of the MVC architectural style are the following:
- Separation of concerns. The main principal of the MVC architectural style is the separation of concerns related to UI processing into three distinct roles: Model, View, and Controller. The Model represents data, the View represents a user interface
and the Controller is used to handle requests and perform operations.
- Use a Passive Model pattern for Improved testability. By decoupling the dependency between the view and model by using the Passive Model MVC pattern you can replace concrete objects with mock objects. The use of mock objects allows you to mimic the
behavior of concrete objects during testing.
- Use events to notify the view of data changes. The Observer pattern is commonly used to provide notifications to the view when data managed by the model is changed.
- Remove processing logic from the view. All processing logic should be handled by the controller instead of the view. However, there are some cases, such as handling events from UI controls, where some processing logic will be required in the view.
If possible the actual logic should be implemented in a controller and event handlers in the view should pass the handling of events off to the controller.
- Use an Active Model pattern with large amounts of data. If you are designing views for handling large amounts of data, consider giving access to the model from the view. This design pattern is a variation of MVC called Active Model.
- Do not mix business logic with UI processing logic. The Controller in MVC should only be responsible for implementing rules related to UI processing. You should never implement business rules within the Controller.
The main benefits of the MVC/MVP architectural style are the following:
- Testability. Since the model and controller are just classes they can be unit tested just like any other class.
- Reusability. The presenter can be reused with other compatible views and vice-versa.
- Manageability. Separation of core concerns helps identify dependencies and organizes the code into more manageable sections.
Some examples of the MVC architectural style are the following:
This architectural style describes the separation of functionality into separate segments in much the same way as the layered style, but with segment being a tier located on a physically separate computer. It evolved through the component-oriented approach,
generally using platform-specific methods for communication instead of a message-based approach. N-tier makes additional demands on hardware and operating systems compared with a layered approach, and is generally viewed as less useful for modern applications
that the layered approach.
The key principles of the N-tier/3-tier architectural style are the following:
- An N-tier application architecture is characterized by the functional decomposition of applications, service components, and their distributed deployment, providing improved scalability, availability, manageability, and resource utilization.
- Each tier is completely independent of all the other tiers, except for those immediately above and below it. The nth tier only has to know how to handle a request from the n+1th tier, and how to forward that request onto the n-1th tier (if there is one),
and handle the results of the request.
- N-Tier architectures have at-least 3 logical layers – or parts – that are separate. Each layer has specific functionality that it is responsible for and is located on physically different servers.
- Additional features or changes to a layer can be done without re-deploying the entire application.
- A layer is deployed on a tier if more than one service or application is dependent on the functionality exposed by the layer.
- A typical implementation of N-Tier architecture is the 3-Tier design which consists of the Presentation Tier, Business Tier and the Data Tier.
- Typically, the Presentation tier hosts the presentation layer (UI processing and rendering), Business Tier hosts the Business Layer (business rules processing) and/or service interfaces and the Data Tier hosts the Data Access Layer (data access logic) and
the data store.
The main benefits of the N-tier/3-tier architectural style are the following:
- Maintainability. Since each tier is independent of the other tier, updates or changes can be carried out without affecting the application as a whole.
- Scalability. Since tiers are based out of layers, scaling out an application is pretty straightforward.
- Flexibility. Since each tier can be managed or scaled independently, flexibility is increased.
- Availability. Applications can make exploit the modular architecture of enabling systems to be divided into easily scalable components, to increase availability.
Some examples of the N-tier/3-tier architectural style are the following:
Object-oriented architecture is a programming 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. An object-oriented design views
a system as a series of co-operating objects, instead of a set of routines or procedural instructions. Objects are discrete, independent, and loosely coupled; they communicate through interfaces, and by sending and receiving messages. An object-oriented architectural
style has the following identifying characteristics:
- It is a style for designing applications based on discrete units of logical and reusable code.
- It describes the use of self-sufficient objects that contain data and the behavior to work with that data, and have a distinct role or responsibility.
- It emphasizes reusability through encapsulation, modularity, polymorphism, and inheritance.
- It contrasts with the procedural approach, where there is a predefined sequence of tasks and actions. The object-oriented approach uses the concept of objects interacting with each other to perform a range of tasks.
The key principles of the object-oriented architectural style are the following:
- Abstraction. This allows you to reduce a complex operation into a generalization that retains the base characteristics of the operation. The generalized version of the operation is used to provide an interface between code that executes the operation
and code that implements the operation. For example, an abstract interface can be a well-known definition that supports data access operations using simple methods such as Get and Update. Another form of abstraction could be metadata used to provide a mapping
between two formats that hold structured data.
- Composition. Objects can be assembled from other objects, and can choose to hide these "internal" objects from other classes, or expose them. The combined object can expose interfaces that simplify common tasks.
- Inheritance. Objects can inherit from other objects, and have access to functionality in the base object. Alternatively, they can inherit from a simpler object and override selected functionality with new behavior to change the way the object works
but still gain the benefits of the other features without repeating the code. This makes maintenance and updates easier, as changes to the base object are propagated through the inheriting objects.
- Encapsulation. Objects expose their functionality through methods, properties, and events. However, they hide the implementation, internal state, and internal variables from other objects and code. This makes it easier to update or replace objects,
providing that their interfaces are compatible, without affecting other objects and code.
- Polymorphism. This allows you to override the behavior of a base type that supports operations in your application.
- Decoupling. This describes separation of the implementation of code from the interface used to execute the code. An object is tightly coupled when the consumer of the object knows about all of the public characteristics of that object. You can decouple
the object from the consumer by defining an abstract interface that the consumer knows about, and that the object implements. This allows you to provide alternative implementations without affecting consumers of the interface.
The main benefits of the object-oriented architectural style are the following:
- Object-oriented design matches the application more closely to the real world requirements.
- The fact that data and behavior are encapsulated makes it easier to:
- Understand what each component does.
- Test each component individually.
- Change the data representation without affecting the interface.
- New objects can be derived from existing objects, which:
- Reduces the development effort.
- Reduces testing requirement (only new features must be tested).
- Provides reuse and extensibility through polymorphism and abstraction.
Many applications in use today use the object-oriented style. Common uses of the object-oriented style include:
- Defining objects that represent real-world artifacts within a business domain, such as a customer or an order.
- Defining an object model that supports complex scientific or financial operations.
Service-Oriented Architecture (SOA)
Service-oriented architecture describes the development of applications that consume functionality from other services, usually Web services. The services exchange information in order to accomplish business processes. This approach implies loose coupling between
services, and supports the use of different operating systems, platforms, and development languages for services. SOA evolved from the principles of object-oriented and component-based design, maximizing the capabilities for loose coupling and the assembly
of complete applications from individual distributed units of functionality. A service-oriented architectural style has the following identifying characteristics:
- It is a technique for designing distributed systems.
- It involves business processes packaged into interoperable services.
- It usually runs on one or more servers.
- Clients and other services can access local services running on the same tier.
- Clients and other services access remote services over connecting network.
- It describes the relationship between the consumer and one or more services, with the client making requests to the service, and the service (usually) sending a response.
- It can use a range of protocols and data formats to communicate information.
The key principles of the SOA architectural style are the following:
- Services are Autonomous. Each service is maintained, developed, deployed, and versioned independently.
- Services are Modular. Each service performs a specific task or set of tasks that are closely related (it is cohesive). Multiple services that perform different sets of tasks can be used to assemble applications.
- Services are Distributable. Services can be located anywhere on a network, locally or remotely, as long as the network supports the required communication protocols.
- Services are Described. Each service exposes information, such as a WSDL service description, that helps users work with the service.
- Services are Sharable. Applications and other services can use services that provide common compatible functionality.
- Services are Loosely coupled. Each service is independent of others, and can be replaced or updated without breaking applications that use it as long as the interface is still compatible.
- Boundaries are Explicit. Operations are called over well-defined boundaries by passing explicitly-defined messages.
- Services share schema and contract, not class. Services share contracts and schemas when they communicate.
- Compatibility is based on policy. Policy in this case means definition of features such as transport, protocol, and security.
The main benefits of the SOA architectural style are the following:
- Reuse of services. Instead of writing components or code modules aimed at reuse, you re-use complete services.
- Interoperability. Services can be combined and reused to create composable interfaces and cross-process applications, exchange information, and interact with a variety of clients and other services.
- Federation opportunities. Applications can take advantage of federated services such as authentication, and unite resources with applications while maintaining autonomy and ensuring that governance policies are applied.
- Domain alignment. Reuse of common services with standard interfaces increases business and technology opportunities and reduces cost.
- Abstraction. Services are autonomous and accessed through a formal contract, which provides loose coupling and abstraction.
- Discoverability. Services expose can descriptions that allow other applications and services to locate them and automatically determine the interface.
Common types of service-oriented application include:
Choosing an Architectural Style
Many factors will influence the architectural styles that you choose. These factors include the capacity of your organization for design and implementation; the capabilities and experience of developers; and the hardware and deployment scenarios available.
As discussed in the Architecture Evolution section, 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 are also effectively choosing Object
Oriented and Component based architecture.
The following guidelines will help you to determine the appropriate styles for your applications.
Client/Server Architectural Style
Consider the client/server architectural style if:
- Your application is server-based and will support many clients.
- You are creating Web-based applications exposed through a Web browser.
- You are implementing business processes that will be used by people throughout the organization.
- You are creating services for other applications to consume.
- You want to centralize data storage, backup, and management functions.
- Your application must support different client types and different devices.
Component-Based Architectural Style
Consider the component-based architectural style if:
- You already have suitable components, or can obtain suitable components from third-party suppliers.
- Your application will predominantly execute procedural-style functions, perhaps with little or no data input.
- Your application is relatively simple, and does not warrant a full layered architecture.
- Your application has specific requirements that do not include a user interface or business processes.
- You want to be able to combine components written in different code languages.
- You want to create a pluggable architecture that allows you to easily replace and update individual components.
Layered Architectural Style
Consider the layered architectural style if:
- You already have suitable layers built for other applications that you can reuse.
- You already have applications that expose suitable business processes through service interfaces.
- Your application is complex, and the high-level design demands separation so that teams can focus on different areas of functionality.
- Your application must support different client types and different devices.
- You want to implement complex and/or configurable business rules and processes.
Message-Bus Architectural Style
Consider the message-bus architectural style if:
- You have existing applications that interoperate with each other to perform tasks.
- You are implementing a task that requires interaction with external applications.
- You are implementing a task that requires interaction with applications hosted in different environments.
- You have existing applications that perform specific tasks, and you want to combine those tasks into a single operation.
Model View Controller (MVC) Architectural Style
Consider the Model View Controller architectural style if:
- You want improved testability and simpler maintenance of UI functionality.
- You want to separate the task of creating the user interface from the logic code that drives it.
- Your UI view does not contain any request processing code.
- Your UI processing code does not implement any business logic.
N-Tier/3-Tier Architectural Style
Consider either the N-tier or the 3-tier architectural style if:
- The processing requirements of the layers in the application differ. Processing on one layer could absorb sufficient resources to slow the processing in other layers.
- The security requirements of the layers in the application may differ. For example, the presentation layer will not store sensitive data, while this may be stored in the business and data layers.
- You want to be able to share business logic between applications.
- You have sufficient hardware to allocate the required number of servers to each tier.
Consider the 3-tier architectural style if:
- You are developing an intranet application where all servers are located within the private network.
- You are developing an Internet application, and security requirements do not restrict implementing business logic within the public facing Web or application server.
Consider using more than three tiers if:
- Security requirements dictate that business logic cannot be deployed to the perimeter network.
- The application makes heavy use of resources and you want to offload that functionality to another server
Object-Oriented Architectural Style
Consider the object-oriented architectural style if:
- You want to model the application based on real-world objects and actions.
- You already have suitable objects and classes that match the design and operational requirements.
- You need to encapsulate logic and data together in reusable components.
- You have complex business logic that requires abstraction and dynamic behavior.
- You have the capacity and resources to perform an in-depth analysis of the business domain.
- You are building an application where the Return on Investment (ROI) outweighs the initial cost of analysis and design.
Service-Oriented Architectural (SOA) Style
Consider the service-oriented architectural style if:
- You have access to suitable services, or can purchase suitable services exposed by a hosting company.
- You want to build applications that compose a variety of services into a single user interface.
- You are creating S+S, SaaS, or cloud-based applications.
- You need to support message-based communication between segments of the application.
- You need to expose functionality in a platform-independent way.
- You want to take advantage of federated services, such as authentication.
- You want to expose services that are discoverable through directories and can be used by clients that have no prior knowledge of the interfaces.
Multiple Architectural Styles
Many applications will use a combination of architectural styles as part of the complete system. For example, you might have a Service Oriented Architecture (SOA) design composed of services developed using a layered architecture approach and object oriented
For more information about architectural styles, see the following articles from
The Skyscrapr Journal