Software Architecture Styles

I’ve been reading Roy Fielding’s dissertation “Architectural Styles and
the Design of Network-based Software Architectures” (http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) in which he introduces the concept of Representational State Transfer (REST).

I really liked his definition of a software architecture style, which I wanted to share with you.

He says:

“A style is a named set of constraints on architectural elements that induces the set of properties desired of the architecture.”

This is quite a mouthful, let’s break it down:

A style is a named set […], meaning that it’s just a name or reference to identify a more abstract concept […] of constraints on architectural elements […]. This is really interesting, because I never thought about it that way: A style is ultimately just a set of constraints, which determine what a software engineer will be able to do or not to do when building software. These constraints will act as a catalyst for a desirable […] set of properties (e.g. performance, scalability, simplicity and so on) that a software engineer is trying to achieve by choosing a particular style over another.

It’s an interesting perspective and I guess he’s right, that an architecture style is much more defined through what not to do (constraints) than about what to do, since there are basically a million different ways to structure software.