Architectural Styles, Patterns, and Metaphors
What’s the difference between an architectural style, an architectural pattern, and a system metaphor? 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. In A Practical Guide to Enterprise Architecture (The Coad Series), James McGovern, Scott W. Ambler, Michael E. Stevens, James Linn, Vikas Sharan, and Elias K. Jo write about the difference between architectural styles, architectural patterns and system metaphors.
Key Take Aways
Here’s my key take aways:
- 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, Patterns, and Metaphors
McGovern, Ambler, Stevens, Linn, Sharan, and Jo write the following:
What’s the difference between an architectural style, an architectural pattern, and a system metaphor? The answer is not much. An architectural style (Base et al. 1997) and an architectural pattern (Buschmann et al. 1996) are essentially synonymous. A system metaphor is similar but more conceptual than an architecture pattern or an architectural style, and it relates more to a real-world concept than to a software engineering concept. An architectural style and an architectural pattern are similar to a design pattern in that they both describe a solution to a problem in a particular context. The only difference is the granularity at which they describe the solution. In a design pattern, the solution is relatively fine grained and is depicted at the level of language classes. In an architectural pattern, the solution is coarser grained and is described at the level of subsystems or modules and their relationships and collaborations. Each subsystem or module within an architectural pattern consists of many language classes that are designed using design patterns.
Example Architectural Styles and Patterns
McGovern, Ambler, Stevens, Linn, Sharan, and Jo provide examples of architectural styles and patterns:
- Model-View-Controller (MVC) architecture pattern. The MVC architecture style is a popular organizing concept for systems. The model represents the data for the system, the view represents the way the data are presented to the user, and the controller handles the logic for the system.
- Publish-subscribe. The publish-subscribe architecture pattern is a system in which a publisher publishes data on a bus. Subscribers subscribe to portions of the data that are published by publishers on the bus. They register for various topics. When a message appears on the bus that matches the topic in which a subscriber is interested, the bus notifies the subscriber. The subscriber can then read the message from the bus.
- Pipes and filters. Anyone who is familiar with UNIX systems will recognize this architectural pattern. The pipe and filter pattern allows a system to be assembled from small programs called filters. A filter has an input and an output. The filters are assembled into a chain in which each filter gets data from the previous filter in the chain, processes the data, and passes the data to the next filter in the chain. The best example of a pipe and filter system is a compiler. The lexical analysis, syntax analysis, semantic analysis, intermediate code generation, and optimization occur in a pipe and filter style chain.
- Layers. A layered system is one in which different layers of the system take care of a specific function of the system. Each layer in a layered architectural style is a package of software that has a well-defined interface and a few well-known dependencies within the application. For example, a data access layer is responsible for encapsulating the technical means for accessing a database. All data requests to a database go through the data access layer for that database. The data access layer has the responsibility of hiding the data access mechanism from upstream layers. In a closed layer system, a layer may only access adjacent layers. In an open layer system, layers may access any other layer in the system, not just the ones to which they are adjacent.