Architectural Patterns
  • Each architecture pattern implements multiple tactics (see Quality Attributes). Tactics are simply design decisions that influence quality attributes
  • Architectural patterns are also called architectural styles; although these might have different meanings…
  • It is difficult to draw a fine line between design and architectural patterns. it depends heavily on the viewpoint of the designer or architect whether a specific pattern is categorized as an architectural pattern or a design pattern and also on the level we want to apply the pattern.
  • Architectural patterns are categorized based on different things by different authors and philosophies. Some of the categorizations are based on:
    1. global system properties that they support
    2. types of components and connectors, and control and data issues;
    3. the concept of architectural views

Basic Patterns (De-compositional)

Distributed Systems

Interactive Systems

Both patterns support the structuring of software systems that feature human-computer interaction.

Adaptable Systems

Both strongly support extension of applications and their adaptation to evolving technology and changing functional requirements.

Modular patterns

Logical design is just one piece of the software design and architecture challenge but the other is modular design, which focuses on the physical entities and the relationships between them.
A software module is a deployable, manageable, natively reusable, composable, stateless unit of software that provides a concise interface to consumers.

See patterns here.

Some of the patterns are:

  • Manage Relationships (Avoid modules with excessive incoming and outgoing)
  • Module Reuse (Emphasize reusability at the module level)
  • Cohesive Modules (Module behavior should serve a singular purpose)
  • Acyclic Relationships (Module relationships must be acyclic)
  • Levelize Modules (Module relationships should be levelized)
  • Physical Layers (Module relationships should not violate the conceptual layers)
  • Independent Deployment (Modules should be independently deployable units)
  • Published Interface (Make a module’s published interface well known)
  • Container Independence (Modules should be independent of the runtime container)
  • External Configuration (Modules should be externally configurable)
  • Module Façade (Create a façade serving as a coarse-grained entry point to another finegrained module’s underlying implementation)
  • Default Implementation (Provide modules with a default implementation)
  • Abstract Modules (Depend upon the abstract elements of a module)
  • Implementation Factory (Use factories to create a module’s implementation classes)
  • Colocate Exceptions (Exceptions should be close to the class or interface that throws them)
  • Separate Abstractions (Place abstractions and the classes that implement them in separate modules)
  • Levelize Build (Execute the build in accordance with module levelization)
  • Test Module (Each module should have a corresponding test module)


  • Pattern Oriented Software Architecture - A System of Patterns By Frank Buschmann, … (POSA)
  • Internet
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License