In Software Engineering, an Architectural Style is a specialized "pattern" or template for the high-level organization of a system. It defines the recurring structural themes that solve common problems in specific contexts.
Choosing a style early in the design phase is crucial because it dictates the system's Quality Attributes—such as how fast it is, how easily it can be changed, and how it handles failure.
🗄️ Data-Centered (Repository) Architecture
In this style, a central data store (like a database or file system) sits at the heart of the architecture. Other independent components (clients) access, add, and modify data within that store.
Key Benefit: Data is integrated and consistent in one place.
Example: A University Management System where the "Student Database" is the center, and the "Grading," "Registration," and "Billing" modules all talk to it.
⚙️ Data-Flow (Pipe-and-Filter) Architecture
This style treats the system as a series of transformations. Data enters a Pipe, is processed by a Filter, and moves to the next pipe.
Key Benefit: Highly modular; you can easily swap or add new filters.
Example: An image processing app (Filter 1: Convert to Grayscale → Filter 2: Adjust Contrast → Filter 3: Export as JPEG).
📞 Call-and-Return Architecture
This is the "classic" programming style. It breaks the system into a hierarchy of subroutines or modules.
Sub-styles: * Main Program/Subprogram: A main routine controls the execution of smaller sub-routines.
Remote Procedure Call (RPC): Components are distributed across a network, but act as if they are local calls.
🍰 Layered Architecture (N-Tier)
The system is organized into layers, each providing a service to the layer above it and acting as a client to the layer below it.
The "Standard" Layers: Presentation (UI) → Application (Logic) → Domain (Business Rules) → Infrastructure (Database).
Key Benefit: You can change the "Infrastructure" layer (e.g., swap MySQL for Oracle) without touching the "UI" layer.
🧊 Object-Oriented Architecture
Components are "Objects" that encapsulate both data and the operations that can be performed on that data. Communication happens via Message Passing.
Key Benefit: Closely models real-world entities and promotes reusability.
📊 Comparing Styles by Quality Attributes
Style | Best For... | Main Strength | Main Weakness |
|---|---|---|---|
Data-Centered | Large-scale data apps | Data Integrity | Central point of failure |
Pipe-and-Filter | Data processing/compilers | Reusability | Low interactive performance |
Layered | Enterprise Web Apps | Maintainability | Can be slow due to "hops" |
Call-and-Return | Simple utility software | Simplicity | Hard to scale |
💡 How to Pick a Style?
There is no "perfect" architecture. You must weigh your Non-Functional Requirements:
Need extreme speed? Avoid too many Layers.
Need to process massive streams of data? Use Pipe-and-Filter.
Need to share a massive amount of complex data? Use Data-Centered.