• Subcribe to Our RSS Feed

Demystifying Architecture vs Design Patterns

Nov 15, 2014 by     No Comments    Posted under: Design, IT Architecture
 

Architecture PatternsPatterns 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:

AttributeDescription
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 ContextThe 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 PatternsThe 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 UsesKnown 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 AreaArchitecture Pattern NameDesign Patterns
Data Integration/SOAETL (Data Extraction Transformation & Loading)Change Data Capture
Near Real-Time ETL
Batch ETL
Data Discovery
EAI/ESBPublish/subscribe
Request/reply
Message Exchange Patterns
Data ArchitectureTransaction Data Stores (TDS/OLTP)
Master Data Store
Operational Data Store
Data Mart
Data Warehouse
Custom Applications Databases
Packaged Application Databases
Business IntelligenceTransactional 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 managementMaster Data HubMaster Data Replication
Master Data Services
Master Data Synchronization
Data ModelingDimensional Data Modeling
E-R Data Modeling
Modeling Standards
Naming Conventions

 

If you enjoyed this post, please consider leaving a comment or subscribing to the RSS feed to have future articles delivered to your feed reader.

Got anything to say? Go ahead and leave a comment!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>