Demystifying Architecture vs Design Patterns
Posted under: 
Patterns are repeated and consistent common characteristics that help in identifying phenomenon, problem or solution. The pattern is well-known concept that has been used for long time across many industries and practices to summarize previous experience and avoid re-inventing the wheel. Patterns were used in natural science, geometry, mathematics, engineering, art, etc.
In software industry, patterns appear in two main contexts: architecture and design patterns. In this post, I am trying to distinguish between both context in a simple way.
Software Architecture describes relationships between various software structures and components (applications, layers, etc.). The architecture is concerned with a larger view of software structure. On the other hand software design is focusing on specific component, application or layer. Accordingly software design is concerned with a smaller context than software architecture.
An Architecture Pattern expresses a fundamental structural organization or schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.
A Design Pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.
An Idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language. For example, we can find idioms using c# or Java.
Architecture patterns are newer than design patterns in software industry. Each architecture pattern is described using below attributes:
| Attribute | Description |
|---|---|
| Name | A meaningful and memorable way to refer to the pattern, typically a single word or short phrase. |
| Problem | A description of the problem indicating the intent in applying the pattern - the intended goals and objectives to be reached within the context and forces described below (perhaps with some indication of their priorities). |
| Context | The preconditions under which the pattern is applicable - a description of the initial state before the pattern is applied. |
| Forces | A description of the relevant forces and constraints, and how they interact/conflict with each other and with the intended goals and objectives. The description should clarify the intricacies of the problem and make explicit the kinds of trade-offs that must be considered. (The need for such trade-offs is typically what makes the problem difficult, and generates the need for the pattern in the first place.) The notion of "forces" equates in many ways to the "qualities" that architects seek to optimize, and the concerns they seek to address, in designing architectures. For example: Security, robustness, reliability, fault-tolerance Manageability Efficiency, performance, throughput, bandwidth requirements, space utilization Scalability (incremental growth on-demand) Extensibility, evolvability, maintainability Modularity, independence, re-usability, openness, composability (plug-and-play), portability Completeness and correctness Ease-of-construction Ease-of-use etc., ... |
| Solution | A description, using text and/or graphics, of how to achieve the intended goals and objectives. The description should identify both the solution's static structure and its dynamic behavior - the people and computing actors, and their collaborations. The description may include guidelines for implementing the solution. Variants or specializations of the solution may also be described. |
| Resulting Context | The post-conditions after the pattern has been applied. Implementing the solution normally requires trade-offs among competing forces. This element describes which forces have been resolved and how, and which remain unresolved. It may also indicate other patterns that may be applicable in the new context. (A pattern may be one step in accomplishing some larger goal.) Any such other patterns will be described in detail under Related Patterns. |
| Examples | One or more sample applications of the pattern which illustrate each of the other elements: a specific problem, context, and set of forces; how the pattern is applied; and the resulting context. |
| Rationale | An explanation/justification of the pattern as a whole, or of individual components within it, indicating how the pattern actually works, and why - how it resolves the forces to achieve the desired goals and objectives, and why this is "good". The Solution element of a pattern describes the external structure and behavior of the solution: the Rationale provides insight into its internal workings. |
| Related Patterns | The relationships between this pattern and others. These may be predecessor patterns, whose resulting contexts correspond to the initial context of this one; or successor patterns, whose initial contexts correspond to the resulting context of this one; or alternative patterns, which describe a different solution to the same problem, but under different forces; or co-dependent patterns, which may/must be applied along with this pattern. |
| Known Uses | Known applications of the pattern within existing systems, verifying that the pattern does indeed describe a proven solution to a recurring problem. Known Uses can also serve as Examples. |
Below table depicts few examples of architectural and related design patterns:
| Sub-Domain Area | Architecture Pattern Name | Design Patterns |
|---|---|---|
| Data Integration/SOA | ETL (Data Extraction Transformation & Loading) | Change Data Capture Near Real-Time ETL Batch ETL Data Discovery |
| EAI/ESB | Publish/subscribe Request/reply Message Exchange Patterns |
|
| Data Architecture | Transaction Data Stores (TDS/OLTP) Master Data Store Operational Data Store Data Mart Data Warehouse | Custom Applications Databases Packaged Application Databases |
| Business Intelligence | Transactional Reporting Operational Reporting Analytical Reporting Security, robustness, reliability, fault-tolerance Manageability Efficiency, performance, throughput, bandwidth requirements, space utilization Scalability (incremental growth on-demand) Extensibility, evolvability, maintainability Modularity, independence, re-usability, openness, composability (plug-and-play), portability Completeness and correctness Ease-of-construction Ease-of-use etc., ... | Transactional Reporting Data Access Operational Reporting Data Access Analytical Reporting Data Access Analytical Dashboard Data Access Operational Dashboard Data Access Data Mining |
| Master data management | Master Data Hub | Master Data Replication Master Data Services Master Data Synchronization |
| Data Modeling | Dimensional Data Modeling E-R Data Modeling | Modeling Standards Naming Conventions |
Related Posts
Service Oriented Architecture (SOA) – Episode 1 (The Origins)
Service Oriented Architecture (SOA) – Episode 2 (Myths and Facts)
Service Oriented Architecture (SOA) – Episode 3 (Services Types)- Service Oriented Architecture (SOA) – Episode 3 (Services Types)
- Service Oriented Architecture (SOA) – Episode 2 (Myths and Facts)
- Service Oriented Architecture (SOA) – Episode 1 (The Origins)
