In building, there are styles known to architects. If you speak of a style, they know what you mean.
An architectural pattern, like an architectural style, imposes a transformation on the design of an architecture. However, a pattern differs from a style in a number of fundamental ways: (1) the scope of a pattern is less broad, focusing on one aspect of the architecture rather than the architecture in its entirety, (2) a pattern imposes a rule on the architecture, describing how the software will handle some aspect of its functionality at the infrastructure level (e.g., concurrency) [Bos00], (3) architectural patterns tend to address specific behavioral issues within the context of the architecture (e.g., how real-time applications handle synchronization or interrupts). Patterns can be used in conjunction with an architectural style to shape the overall structure of a system.
Data Centered
A data store (e.g., a file or database) resides at the center of this architecture and is accessed frequently by other components that update, add, delete, or otherwise modify data within the store.
Data-Flow Architectures
This architecture is applied when input data are to be transformed through a series of computational or manipulative components into output data. A pipe-and-filter pattern has a set of components, called filters, connected by pipes that transmit data from one component to the next.
Each filter works independently of those components upstream and downstream, is designed to expect data input of a certain form, and produces data output (to the next filter) of a specified form. However, the filter does not require knowledge of the workings of its neighboring filters.
Call and Return Architectures
This architectural style enables you to achieve a program structure that is relatively easy to modify and scale.
Layered Architectures
These architectural styles are only a small subset of those available. Once requirements engineering uncovers the characteristics and constraints of the system to be built, the architectural style and/or combination of patterns that best fits those characteristics and constraints can be chosen. In many cases, more than one pattern might be appropriate and alternative architectural styles can be designed and evaluated. For example, a layered style (appropriate for most systems) can be combined with a data-centered architecture in many database applications.
Architecture Considerations
There are things you have to consider when you choose a style to use:
Economy—Many software architectures suffer from unnecessary complexity driven by the inclusion of unnecessary features or nonfunctional requirements.
The best software is uncluttered and relies on abstraction to reduce unnecessary detail.
Visibility—As the design model is created, architectural decisions and the reasons for them should be obvious to software engineers who examine the model at a later time.
Spacing—Separation of concerns in a design without introducing hidden dependencies is a desirable design concept that is sometimes referred to as spacing. Sufficient spacing leads to modular designs, but too much spacing leads to fragmentation and loss of visibility. Methods like domain-driven design can help to identify what to separate in a design and what to treat as a coherent unit.
Symmetry—Architectural symmetry implies that a system is consistent and balanced in its attributes. Symmetric designs are easier to understand, comprehend, and communicate.
Example: A customer account object whose life cycle is modeled directly by a software architecture that requires both open() and close() methods. Architectural symmetry can be both structural and behavioral.
Emergence—Emergent, self-organized behavior and control are often the key to creating scalable, efficient, and economic software architectures. For example, many real-time software applications are event driven. The sequence and duration of the events that define the system’s behavior is an emergent quality. It is very difficult to plan for every possible sequence of events. Instead the system architect should create a flexible system that accommodates this emergent behavior.
Architecture Styles was originally found on Access 2 Learn
