Skip to content

Software architecture patterns

Concept · Chapter 7

  • A codified, reusable solution to a recurring problem that is well understood in a particular context.
  • Every pattern combines three parts: a context, a problem, and a solution.
  • The problem may be a challenge to overcome, an opportunity to exploit, or one/more quality attributes to satisfy.
  • Patterns give a shared vocabulary: naming one communicates a whole solution without explaining every detail.
Architecture patternsDesign patterns
Broader scope, applied at architecture levelApplied during implementation
Coarse-grainedFine-grained
High-level structure + behavior of the whole systemSolve localized coding problems
  • An architecture pattern is a grouping of design decisions repeated and used successfully for a context.
  • It introduces design constraints that reduce complexity and help prevent bad decisions.
  • Followed consistently, a pattern lets you anticipate the properties the system will exhibit — you can judge up front whether the design meets requirements and quality attributes.
  • You mostly discover and reuse existing patterns rather than inventing them. A novel solution only becomes a pattern once repeated successfully in practice.
  • Patterns can apply to the whole system or to a subsystem — so multiple patterns can coexist in one system and be combined to solve problems.
  • Overuse is a common mistake. Do not force a pattern just because you know it. Use one only when it is the best fit for the design issue and context.

Architecture style vs architecture pattern

Section titled “Architecture style vs architecture pattern”
  • Often used interchangeably; the distinction is not clear-cut and varies by source.
  • Style: a set of elements and the vocabulary for them, available to an architecture — it constrains design by restricting choices (e.g. the microservice style constrains services to be independent, yielding independent deployment, fault isolation, per-service tech choice).
  • Pattern: a particular arrangement of a style’s available elements into a solution for a recurring problem in a context.
  • This chapter does not dwell on the distinction and mostly uses the term “software architecture pattern.”
  • Software Architect’s Handbook (Packt, 2018), Ch.7 “Software architecture patterns”, pp. 495-499.