Many of the technical problems software architects face are not new. As a broader software architecture community, we’ve been building scalable, maintainable, reliable, highly available, testable software systems across a variety of technical domains for decades. Apart from a small handful of emerging problem areas, many of today’s software design problems have known solutions. Patterns describe these known solutions.
An architecture pattern is a reusable solution to a specific problem. Software architecture patterns show how to promote specific quality attributes by using a specific combination of structures. Choose the right patterns for our problem, and we can avoid nasty traps that may otherwise cause trouble had we attempted to design the architecture from scratch.
Patterns have many other benefits. Since many patterns are widely known, we get communication bonuses by using them. If a picture is worth a thousand words, a pattern is worth a thousand pictures. Popular patterns are baked into frameworks and platforms, making it easier to adopt them.
Let’s explore some of the more common architecture patterns in use today. The mini-catalog here is far from a complete list. More information about each pattern can be found easily on the web and in existing architecture literature.
Design patterns are an essential design tool for all designers regardless of design discipline or granularity of abstraction. You’ll find design patterns for user experience, testing, database design, and even engineering processes, in addition to programming, software architecture, and enterprise architecture. All design patterns have a place in modern software development.
Architecture patterns differ from programming design patterns, such as those cataloged by the Gang of Four in Design Patterns: Elements of Reusable Object-Oriented Software [GHJV95], by the types of problems they aim to solve. The Gang of Four’s design patterns shows how to organize object-oriented programs to promote reusability and maintainability. Architecture patterns define solutions for a variety of quality attributes scenarios—design time, runtime, and conceptual—and often deal with multiple components of a software system. The scope is broader in an architecture pattern regarding both the quality attributes and the granularity of abstractions in play.
In practice, distinguishing programming design patterns from architecture design patterns isn’t so important. After all, one person’s architecture might be another person’s detailed design.
3.147.193.141