Modeling – Architectural Styles

I claimed in the past (see “What’s software architecture”) that Architecture is a type of design – if that is true, an interesting question is, do we also have architectural patterns?

I think the answer is yes – there are architectural patterns they are also called architectural styles – I actually like this term better as it helps differentiate them from design patterns; for example, I agree with  Harry Pierson’s observation that many of the patterns in Martin Fowler’s PoEAA are indeed technical patterns at an engineering or design level and not architectural patterns.

The difference between architecture styles and design patterns is similar to the distinction between architecture and design – architectural styles affect the solution globally or at least it affects major parts of the solution and not solve local issues. However, it is interesting to note that some architectural styles were known well before the notion of design patterns for software was introduced.

SEI’s architecture glossary defines Architecture Style as

“A specialization of element and relation types, together with a set of constraints on how they can be used.”

That’s a good start, but it might be a little hard to understand. We can basically say that an architectural style defines a family of solutions in terms of a pattern of structural organization using a vocabulary of components and connector types (plus constraints on their use). It is also worth mentioning that different styles can be combined to create compound or derived styles.

I’ll try to illustrate what a style is using an example:

One of the basic architectural styles is “Layered architecture”:

The layered style is composed of layers (the components) that provide facilities and have specific roles. The layers have communication paths/dependencies (the connectors).

In a layered style, a layer has some limitations on how it can communicate with other layers (the constraints). Typically, a layered is allowed to call only the layer below it and be called only by the layer above it (but there are variants, e.g., a layer can call to any layer below it; vertical layers that can call multiple layers, etc. – as long as the layers communication paths are limited by some rules)

You can see the application of layered style all over the place for instance, logical software layers (e.g., presentation component, UI Controllers, business processes, business components, data entities, data access layer), SOA layers (fundamental, Intermediate, Process), physical tiers (like database servers, application servers, web servers, and clients), etc.

There are many other architecture styles, including, for example, pipe and filter, push-based, peer-to-peer, blackboard, MVC, PAC, or the more recent Adaptive Object Models, REST and SOA (some will probably disagree that SOA is a style – but I’ll try to explain why I think it is on another opportunity). I’ll try to talk a little about some of them in the next posts.